The openSUSE community has published the End of the Year Community Survey results.

The results provided some significant information about the project’s tools, its distributions, the demographics of the users as well as how the community is contributing to the project.

The highest percentage of users were between the ages of 35 and 49, according to the results. More than half the respondents were from Europe; the Americas made up roughly a quarter of the respondents and Asia 10 percent. Both Oceania and Africa respondents had similar percentages below 2 percent.

The respondents were predominantly males working in the IT industry with more than 10 years experience with a NIX system; almost half were college educated. A little less than 20 percent were pursuing an education and under the age of 25. Many identified themselves as tech hobbyists and used both openSUSE Leap and Tumbleweed equally. A majority of contributors to the project provided user support or did packaging and maintenance.

The majority of respondents used KDE’s Plasma for their desktop environment followed closely by GNOME and Xfce respectively; more than 92 percent were satisfied or very satisfied with the desktop environment. Use of Graphics Processing Units were pretty evenly split between Intel, Nvidia and AMD respectively.

Less than 900 respondents identified pain points, which were evenly spread around topics like finding software, installing software, installation, unsupported hardware and documentation. A large majority were unaware of openSUSE on mobile, but expressed interest in the comments section.

Many seemed to be motivated to try openSUSE from blogs, magazine articles or through podcasts, yet a large majority of respondents felt openSUSE was underrated/underrepresented by open source and Linux influencers.

More details about the End of the Year Community Survey results can be found on the openSUSE Wiki.

En este día de reyes me apetece compartir los 12 mejores juegos en Linux del 2020 según Make Tech Easier, un listado que demuestra que jugar en GNU/Linux no es algo imposible.

12 mejores juegos en Linux del 2020 según Make Tech Easier

Cada cierto tiempo me gusta hacer un artículo como este, y suele ser enero el mes más habitual para hacerlo. El año pasado hice uno con los 12 juegos gratuitos y de código abierto para GNU/Linux y este año me he decido por juegos más comerciales.

El objetivo de hacerlo es mostrar que jugar en GNU/Linux no es solo posible sino que en muchas ocasiones funciona incluso mejor.

En esta ocasión los creadores del vídeo son Make Teach Easier y nos ofrecen sus 12 mejores juegos en Linux del 2020, la mayor parte de ellos utilizando proton de Steam pero plenamente funcionales. Los hay de todo tipo y de precios variados (incluso gratuitos), así que no hay excusa.

Como es habitual, a continuación hago el listado de los mismos por si alguien simplemente quiere la información:

• A Short hike: un precioso juego que tiene como objetivo subir una montaña desarrolado y publicado por el programador canadiense Adam Robinson-Yu. Vía: wikipedia
• Crusaders Kings 3: juego de gran estrategia ambientado en la Edad Media, desarrollado por Paradox Development Studio y publicado por Paradox Interactive como secuela de Crusader Kings (2004) y Crusader Kings II (2012). Via: wikipedia
• Total War: Warhammer 2: otro videojuego de estrategia desarrollado por The Creative Assembly. Vía: wikipedia
• Desperados 3: videojuego de táctica de tiempo real desarrollado por Mimimi Games y publicados por THQ Nordic. Vía: wikipedia
• Dying Light: Enhaced Edition: juego de acción en primera persona del género Horror de supervivencia, el cual se desarrolla durante un apocalipsis zombie. Vía: wikipedia
• Sid Meier’s: Civilization VI: videojuego de estrategia por turnos perteneciente a la serie Civilization. El juego fue desarrollado por Firaxis Games y distribuido por 2K Games y Take-Two Interactive. Vía: wikipedia

• Pillars of eternity II: Deadfire: Juego de rol desarrollado por Obsidian Entertainment y publicado por Versus Evil. . Vía: wikipedia
• Slay the Spire: videojuego roguelike, RPG de cartas y mazmorras desarrollado por MegaCrit y publicado por Humble Bundle. Vía: wikipedia
• Dead Cells: videojuego híbrido entre el género de exploración de mazmorras o roguelike, y metroidvania, creando su propio género, “roguevania”, desarrollado por el estudio Motion Twin. Vía: wikipedia
• Team Fortress 2: videojuego multijugador de disparos en primera persona desarrollado y publicado por Valve Corporation. Vía: wikipedia
• Dota 2: videojuego perteneciente al género de Arena de batalla en línea ARTS («estrategia de acción en tiempo real»), también conocido como MOBA. Vía: wikipedia
• Juegos Open-Source: no se trata de un juego sino un listado rápido de juegos libres y gratuitos como la saga Doom.

¡Feliz día de Reyes!

C'est l'heure des élections !

Deux sièges sont à pourvoir au sein du conseil d'administration d'openSUSE. Gertjan Lettink a terminé son deuxième mandat. Simon Lees a terminé son premier mandat et il peut donc se présenter de nouveau comme candidat au Conseil s'il le souhaite.

Le calendrier des élections est le suivant :

Phase 0

5 décembre 2019

• Annonce de l'élection du Conseil d'administration d'openSUSE 2019-2020

• Appel pour les nominations et les candidatures au conseil d'administration

• Campagne d'adhésion. Devenez un membre openSUSE. Profitez de l'occasion pour faire une demande d'adhésion à openSUSE pendant cette phase (afin de voter ou de vous présenter comme candidat).

25 décembre 2019

• Clôture des nominations et des candidatures au Conseil d'administration

Phase 1

26 décembre 2019

• Annonce de la liste finale des candidats

• Début de la campagne

• La campagne d'adhésion se poursuit, possibilité de faire une demande d'adhésion à openSUSE, mais les membres ne pourront voter et ne pourront pas se présenter comme candidats.

Phase 2

16 janvier 2020

*Les scrutins sont ouverts : Veuillez voter pendant ce temps

• La campagne se poursuit

31 janvier 2020

• Fermeture des scrutins

1er février 2020

• Annonce des résultats

Le Comité des élections est composé d'Edwin Zakaria et d'Ish Sookun.

Seuls les membres d'openSUSE sont éligibles. Toutefois, les membres du comité d'élection ne sont pas admissibles à se présenter afin d'éviter les conflits d'intérêts. Pour postuler à un poste au sein du conseil d'administration d'openSUSE, veuillez envoyer un e-mail à :

• opensuse-project@opensuse.org et * election-officials@opensuse.org

Si un membre désire proposer la candidature de quelqu'un d'autre, veuillez en informer le comité d'élection et les responsables communiqueront avec le candidat pour lui demander s'il désire se porter candidat au conseil.

Le comité d'élection lance un appel de candidatures et de candidatures pour le conseil d'administration d'openSUSE.

Tal y como estaba previsto en el calendario de lanzamiento de los desarrolladores, hoy martes 5 de enero la Comunidad KDE ha comunicado que ha sido lanzada la quinta actualización de Plasma 5.20. Una noticia que aunque es esperada y finalizando las fiestas navideñas es la demostración palpable del alto grado de implicación de la Comunidad en la mejora continua de este gran entorno de escritorio de Software Libre.

Lanzada la quinta actualización de Plasma 5.20

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las actualizaciones.

De esta forma, el martes 5 de enero ha sido lanzada la tercera actualización de Plasma 5.20, la cual solo trae (que no es poco) soluciones a los bugs encontrados en esta semana de vida del escritorio y mejoras en las traducciones. Es por tanto, una actualización 100% recomendable.

Más información: KDE

Las novedades básicas de Plasma 5.20

Os dejo las novedades más destacada de esta nueva versión son:

• La barra de tareas por defecto será la de Solo Iconos, y además será un poco más ancho (una de las primeras cosas que suelo cambiar cuando configuro mi escritorio)
• Las visualizaciones en pantalla (OSD) que aparecen al cambiar el volumen o el brillo de la pantalla (por ejemplo) se han rediseñado para ser menos intrusivas.

• Ahora se notifica cuando el sistema está a punto de agotar el espacio incluso si el directorio personal es a una partición diferente.
• Ahora se pueden componer mosaicos con las esquinas de las ventanas combinando los atajos de mosaico izquierda/derecha/arriba/abajo. Por ejemplo, pulsando Meta+flecha arriba y después la flecha izquierda para hacer el mosaico de una ventana a la esquina superior izquierda.
• Las páginas de Configuración de Inicio automático, Bluetooth, y Gestión de usuarios se han rediseñado según los estándares modernos de interfaz de usuario y se han reescrito desde cero.
• Notificaciones de monitorización y fallo de discos S.M.A.R.T

If I look back at the last post I made on ths blog… let’s say quite a lot of time has passed. The reason? Well, first of all, one would call it a lack of motivation¹, and afterwards, the emergence of a small yet quite annoying pathogen which caused a bit of a stir worldwide. But today I’m not going to talk about viruses: perhaps some other time when you can avoid hear about it for breakfast, lunch, and dinner.

KDE software from git and the OBS

Yes, today I’m going to talk about the OBS, that is the Open Build Service, not to be confused with another highly successful open source project.

As you know, since ages, the openSUSE KDE team provides a series of repositories which track the latest state of the git repositories in KDE, be them either Frameworks, Plasma, or the applications part of the Release Service. This also allows to create Live CDs which can be useful for testing out the software.

But the question that I’ve seen every now and then is… how it is actually done? Is everything provided by the OBS, or does someone need to add some glue on top of that?

Using the OBS to provide updates to KDE packages from git

Source services

From the official documentation:

Source Services are tools to validate, generate or modify sources in a trustable way.

Ok, that doesn’t tell us much, does it? Luckily, the concept is simple. It is that, for packages built in the OBS, we can use tools (internal or external) to perform operations on the source(s) the packages are built from. These are done before any actual building starts.

The openSUSE wiki has some examples of what a source service can do, of which one immediately jumps to our eye:

Checkout service - checks out from SVC system (svn, git, …) and creates a tarball.

That means that we can, theoretically, ask the OBS to do a checkout from git, and automatically generate a tarball from there. In addition, a source service can add version information to the RPM spec file - the blueprint of an openSUSE package - including some data taken off git, for example the date and the revision hash of the checkout.

Source services are implemented as files named _service which live in the OBS for each package. Let’s take a look at the one for kcoreaddons in the KDE:Unstable::

<services>
  <service name="obs_scm">
    <param name="url">https://invent.kde.org/frameworks/kcoreaddons.git</param>
    <param name="scm">git</param>
    <param name="versionformat">VERSIONgit.%ci~%h</param>
  </service>
 <service name="set_version_kf5" mode="buildtime"/>
  <service mode="buildtime" name="tar" />
  <service mode="buildtime" name="recompress">
    <param name="file">*.tar</param>
    <param name="compression">xz</param>
  </service>
  <service mode="buildtime" name="set_version" />
</services>

obs_scm

The first line inside service tells us that we’re using the obs_scm service, which is a built-in service in openSUSE’s OBS instance to checkout the sources from the url, using git. The versionformat parameter sets the version to a literal VERSION (more on that later) and adds the git suffix, and then adds %ci, which is replaced by the checkout date (example: 20210102T122329) and %h, which puts the short git revision hash in the version (example: 5d069715).

The whole data is compressed in a cpio archive with the obscpio extension. At this point, we don’t have a tarball yet.

After the checkout

THe next services run when the package is actually built, as you can see by the mode="builtime" in their definitions. The first one (set_version_kf5) is actually a service made by Fabian Vogt (fellow member of the KDE team) which replaces VERSION by the current version present in the KDE git (done manually: it is read from the OBS project configuration, and bumped every time it happens upstream). The following lines set the version in the spec file, and compress the whole thing into a tarball.

At this point, the build system starts building the actual source and creating the package.

Manual labor

Just when are these kind of source services run? If left by themselves, never. You need to actually signal the OBS (trigger, in OBS-speak) to run the service. An example is with the osc command line utility:

osc service remoterun KDE:Unstable:Frameworks kcoreaddons

Or there’s a button in the OBS web interface which can allow you to do just that:

There’s just a little problem. When there are more than 200 packages to handle, updating in this way gets a complicated. Also, while the OBS is smart enough to avoid updating a package that has not changed, it has no way to tell you before the service is actually run.

Automation

Luckily, the OBS has features which, used with some external tools, can solve the problem in a hopefully effective way.

Since 2013 the OBS can use authentication tokens to run source services, and you can for example trigger updates with pushes to GitHub repositories. To perform this task for the KDE:Unstable repositories, I based upon these resources to build something to do mass updates in a reliable way.

First of all, I generated a token, and I wanted to make sure that it could only trigger updates. Nothing more, nothing less. This was fairly easy with osc:

osc token --create -o runservice

I did not specify a project, so the token works with all the repositories I have access to. This was a requirement, because the KDE Unstable repositories are actually three different OBS projects.

To trigger an update in the OBS, one needs to call the https://api.opensuse.org/trigger/runservice endpoint, doing a POST request and include the project name (project parameter) and the package name (package parameter). An example (I know, I didn’t encode the URL for simplicity, bear with me):

https://api.opensuse.org/trigger/runservice?project=KDE:Unstable:Frameworks&package=kcoreaddons

The token needs to be passed as an Authorization header, in the form Token <your token here>. You get a 200 response if the trigger is successful, and 404 in other cases (including an incorrect token).

Like this, I was able to find a way to reliably trigger the updates. In fact, it would be probably easy to conjure a script to do that. But I wanted to do something more.

A step further

I wanted to actually make sure to trigger the update only if there were any new commits. But at the same time I did not want to have a full checkout of the KDE git repositories: that would have been a massive waste of space.

Enter git ls-remote, which can give you the latest revision of a repository for all its branches (and tags), without having to clone it. For example:

git ls-remote --heads https://invent.kde.org/pim/kitinerary.git/
22175dc433dad1b1411224d80d77f0f655219122        refs/heads/Applications/18.08
5a0a80e42eee138bda5855606cbdd998fffce6c0        refs/heads/Applications/18.12
2ca039e6d4a35f3ab00af9518f489e00ffb09638        refs/heads/Applications/19.04
2f96d829f28e85f3abe486f601007faa2cb8cde5        refs/heads/Applications/19.08
f12f2cb73e3229a9a9dafb347a2f5fe9bd6c7975        refs/heads/master
18f675d888dd467ebaeaafc3f7d26b639a97d142        refs/heads/release/19.12
90ba79572e428dd150183ba1eea23d3f95040469        refs/heads/release/20.04
763832e4f1ae1a3162670a93973e58259362a7ba        refs/heads/release/20.08
c16930a0b70f5735899826a66ad6746ffb665bce        refs/heads/release/20.12

In this case I limited the list to branches to branches (--heads). As you can see, the latest revision in master for kitinerary at the time of writing is f12f2cb73e3229a9a9dafb347a2f5fe9bd6c7975. So, the idea I had in mind was:

1. Get the state of the master branch in all repositories part of the KDE Unstable hierarchy;
2. Save the latest revision on disk;
3. On the following check (24 hours later) compare the revisions between what’s stored on disk and the remote;
4. If the revisions differ, trigger an update;
5. Save the new revision to disk;

This was slightly complicated by the fact that package names on the OBS and source repositories in KDE can differ (example: plasma-workspace is plasma5-workspace or akonadi is akonadi-server). My over-engineered idea was to create a JSON mapping of the whole thing (excerpt):

{
    "KDE:Unstable:Frameworks": [
        {
            "kde": "frameworks/attica",
            "obs": "attica-qt5",
            "branch": "master"
        },
        {
            "kde": "frameworks/kdav",
            "obs": "kdav",
            "branch": "master"
        }
    ]
}

(Full details on the actual repository)

It was painful to set up the first time, but it paid off afterwards. I just needed a few more adjustments:

• Check whether the remote repository actually existed: I used GitLab’s project API to obtain a yes/no answer for each repository, and skip them if they do not exist.
• Commit the changed files to git and push them to the remote repository holding the data.

As I am mostly a Python person, I just used Python to write a yet another over-engineered script to do all the steps outlined above.

Icing on the cake

Mmm… cake. Wait. We’re not talking about food here, just about how the whole idea was put into “production” (include several hundred of quotes around that word). I created a separate user on my server (the same which runs dennogumi.org) with minimal privileges, put the token into a file with 0600 permissions, and set up a cron job which runs the script every day at 20 UTC+1.

There was just one extra step. Historically (but this is not the case anymore nowadays) the OBS would fail to perform a git checkout. This would leave a package in the broken state, and the only way to recover would be to force an update again (if that did not fix it, it would be time to poke the friendly people in #opensuse-buildservice).

Inspired by what a former KDE team member (Raymond “tittiatcoke” Wooninck) did, I wrote a stupid script which checks the packages in broken state (at the moment just for one repository and one architecture: a broken clone would affect all of them equally) and forces an update. It needs to use tokens rather than osc, but I’ll get to that soon, hopefully.

Conclusion

There, you have it. This is how (at the moment) I can handle updating all KDE packages from git in the OBS with (now) minimal effort. Probably it is an imperfect solution, but it does the job well. Shout out to Fabian who mentioned tokens and prompted the idea.

Even though it does not look like it does, the BPI-M2 Zero also has a wired ethernet interface. Unfortunately, it is disabled by default in its device tree blob.

But enabling it is easy:

# copy into /root
cp /boot/dtb/sun8i-h2-plus-bananapi-m2-zero.dtb .
# decompile
dtc -I dtb sun8i-h2-plus-bananapi-m2-zero.dtb \
    -O dts -o sun8i-h2-plus-bananapi-m2-zero.dts
# edit
vi sun8i-h2-plus-bananapi-m2-zero.dts # :-)
# compile
dtc -i dts sun8i-h2-plus-bananapi-m2-zero.dts \
    -O dtb -o /boot/custom.dtb

lichess.org es uno de los servidores dedicados al ajedrez sin anuncios, gratuito para disfrutar de todas sus opciones y creado con software libre

Cual gambito de dama, abro la partida de publicaciones en el blog de este nuevo año 2021, ofreciendo un nuevo artículo, para ti fiel lector o lectora que recalas de manera casual o premeditada a este pequeño rincón propio del proceloso internet.

Y en esta ocasión escribo sobre ajedrez, ese gran juego (o más que eso) enigmático, infinito e inabarcable que pone a prueba nuestra inteligencia y ejercita nuestras neuronas, memoria, y un sin fín de cosas más.

Ya desde los duelos míticos del siglo pasado entre Kasparov y Karpov, el ajedrez es algo que alguna vez me llamó la atención, pero que por mis nulas cualidades a la hora de jugar dejé de lado.

También porque no era algo muy popular en la pequeña ciudad donde vivo, y jugar con alguien más era algo muy difícil. Pero hoy en este recién estrenado 2021 del siglo 21, jugar partidas en línea con otros oponentes gracias a internet es muy sencillo.

Hay muchos servidores de ajedrez, de diversos tipos y características. Los hay de pago, gratuitos con ciertas opciones de pago, con unas opciones u otras.

De entre todas las opciones que existen, hoy quería dar a conocer y difundir sobre lichess.org, un servidor de ajedrez libre, gratuito y con el código fuente publicado bajo licencias libres y disponible en GitHub.

lichess.org es un servidor de ajedrez sin publicidad, soportado por una comunidad que lo mantiene con código y donaciones, que puedes visitar de manera anónima o puedes abrirte una cuenta para mantener un registro de tus progresos, interactuar en la comunidad, etc.

Porque lichess.org es más que un sitio para solo jugar a ajedrez. Es un lugar donde aprender, desde lo básico e ir progresando y avanzando en dificultad y conocimientos. También puedes ir practicando y conociendo los movimientos, ataques, aperturas y demás tácticas del ajedrez.

También por supuesto es un lugar de encuentro para librar partidas con jugadores y jugadoras de todo el mundo. Partidas de diversa duración y diversas características, torneos.

Y más, porque también es una “comunidad” donde compartir con esas personas, en sus partidas retransmitidas, foro, etc.

Podrás estudiar más tarde tus partidas, repetirlas, cambiar la jugada, etc. Podrás exportar partidas e importarlas, jugar contra la máquina, aprender y disfrutar del ajedrez.

También puedes crear grupos o unirte a algún grupo con intereses comunes con personas que conozcas y jugar partidas.

En el apartado estético, la web está traducida al español entre otros muchos idiomas, gracias a la comunidad. Tiene un estilo moderno y creo que bastante funcional.

También dispone de una API documentada para poder crear clientes que interactúen con el servidor y tu cuenta. También de aplicación para Android disponible desde la tienda de Google.

Tiene la opción de tema oscuro o claro y por supuesto muchas otras opciones de “customización” a la hora de escoger color del tablero, tipos de piezas, vista en 2D o 3D y otras opciones.

Y todo esto creado con un software licenciado bajo licencias libres y con el código disponible en GitHub. Lo que para mí es un aliciente importante y muy interesante.

Desde hace un tiempo lo estoy visitando en modo anónimo, pero estoy pensando en abrirme una cuenta, para ir aprendiendo lo básico a la hora de enfrentarte al tablero de ajedrez y guardar mis progresos.

Sí, ya sabía mover las piezas por el tablero, ¡pero iba a lo loco! sin pies ni cabeza, ni estrategia, ni visión. No espero convertirme en un experto, simplemente disfrutar del ajedrez de vez en cuando y aprender. ¿echamos una partida?

Enlaces de interés

• https://lichess.org/
• https://github.com/ornicar/lila
• https://en.wikipedia.org/wiki/Lichess

Siempre lo comento, KDE Blog es un blog que prácticamente lo lleva solo una persona pero siempre está abierto a colaboraciones de otros (y de hecho las agradezco). Este es el caso de Héctor Sales, usuario entusiasta de GNU/Linux y amigo que nos presentó hace tiempo Cómo instalar Nvidia Optimus en Debian o Cómo instalar Nvidia Optimus en Ubuntu, y que hoy nos trae otro interesante artículo titulado «Guía de Nvidia Optimus en Debian (Intel + Nvidia)» con el que optimizar el uso de nuestro hardware. Espero que os sea de utilidad.

Guía de Nvidia Optimus en Debian (Intel + Nvidia)

Después de algún tiempo hemos decido actualizar la guía de Nvidia Optimus en Debian (Intel +Nvidia).

Estos son los dos métodos soportados:

• Using PRIME Render Offload (Método recomendado por nvidia y solamente disponible a partir de Debian 11 actual Testing, se necesita la versión de xorg 1.20.7 o superior).
• Using NVIDIA GPU as the primary GPU (que saldrá publicado más tarde)

Empezaremos con el primero, el cual nos permite utilizar nuestra gráfica intel integrada como predeterminada y la tarjeta nvidia dedicada para tareas más específicas.

Mi sistema actual es Debian Testing KDE y mis GPU’s :

Partimos de la base que ya tenemos instalado el driver de nvidia en Debian Testing, sino es así:

$ sudo apt install nvidia-driver

..o bien:

$ sudo apt install nvidia-detect

Una vez instalado el driver privativo de nvidia, creamos el archivo nvidia.conf, en la ruta «/etc/X11/xorg.conf.d» con el siguiente contenido:

$ sudo nano /etc/X11/xorg.conf.d/nvidia.conf
Section «ServerLayout»
Identifier «layout»
Option «AllowNVIDIAGPUScreens»
EndSection

Después podemos cerrar sesión o, mejor aún, reiniciar la máquina para asegurarnos todos los cambios.

Una vez logeados en el sistema podemos añadir esto a nuestro .bashrc o .bash_aliases lo siguiente:

prime () {
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia "$@"
}

Cada vez que queramos ejecutar con nuestra nvidia algún programa solamente tenemos abrir una consola y escribir lo siguiente:
Ejemplo :

$ prime firefox

Y próximamente explicaremos el otro método soportado: Using NVIDIA GPU as the primary GPU

Der Klett Verlag bietet zu vielen seiner Lehrwerke auch Begleitmaterialien auf CD ROM an. Die Anwendung auf diesen CDs öffnet tatsächlich nur HTML-Datei, so dass sich die CDs durch direktes Öffnen der Datei index.html Datei auch wunderbar auf nicht-Windows-Systemen nutzen ließen. Häufig wird dann aber eine kaputte Seite dargestellt, und die Fehlerkonsole des Browsers beschwert sich über fehlende Dateien, z.B. für die Schriftarten. Des Rätsels Lösung ist, dass diese Dateien auf der Ebene des Joliet-Dateisystems als versteckt markiert sind und für Anwendungen so normalerweise nicht sichtbar sind. Unter Windows kümmert sich die Klett-Anwendung darum diese vor dem Öffnen der index.hml sichtbar zu schalten.

Mit dem Wissen darum, dass die Dateien auf Dateisystemebene versteckt sind, kann man die CDs auch unter Linux wunderbar nutzen. Die Lösung findet sich dann beispielsweise auf askubuntu.com: Die CD muss mit der Option unhide eingebunden werden.

Während normalerweise auch Nutzer CDs mounten können, muss dies in diesem Fall allerdings durch Root gemacht werden, da Nutzer keine Optionen beim Mounten angeben dürfen. Auf meinem openSUSE-System führe ich also folgende Schritte aus:

mkdir /tmp/klett
sudo mount -o unhide -t iso9660 /dev/sr0 /tmp/klett

Danach ist die CD mit allen Dateien in /tmp/klett verfügbar und ich kann z.B. mit einem xdg-open /tmp/klett/index.html den Inhalt öffnen.

Zur Erklärung der obigen Kommandozeile:

• Mit mkdir /tmp/klett lege ich ein temporäres Verzeichnis an. Es in /tmp anzulegen erspart es mir hinterher aufräumen zu müssen.
• sudo ist Notwendig, da ein normaler Nutzer keine Optionen angeben kann.
• -o unhide macht die normalerweise versteckten Dateien sichtbar.
• -t iso9660 gibt explizit an welches Dateisystem verwendet wird. mount kann dies normalerweise auch automatisch erkennen.
• /dev/sr0 ist mein optisches Laufwerk.