Hoy me congratula comentaros que ha sido lanzado Inkscape 1.2. De esta forma el magnífico editor de dibujos vectoriales sigue su evolución con jugosas novedades como la posibilidad de tener multippáginas en un solo documento, un gran avance en mi modesta opinión.

Lanzado Inkscape 1.2, ahora multipágina

Una de las aplicaciones que más me gustan cuando tengo de diseñar alguna cosa es Inkscape. Su potencia y versatibilidad la hacen maravillosa, y sus posibilidades simplemente están limitadas por tu imaginación y arte… los cuales son escasos en mi caso.

Pero eso no es impedimento para que este maravilloso proyecto siga adelante y nos acabe de presentar su versión 1.2, que según leemos en la página oficial de Inkscape, llega con las siguientes novedades:

• Los documentos de Inkscape ahora pueden contener múltiples páginas, que se gestionan con la nueva herramienta Página
• Marcadores editables y patrones de guiones
• Diálogo de capas y objetos fusionado
• Rediseño de la alineación en el lienzo y de los paráemetros de los ajustes
• Nuevo efecto «Tiling» Live Path
• Diálogo de exportación rediseñado con vista previa y capacidad para seleccionar objetos/capas/páginas e incluso múltiples formatos de archivo a los que exportar
• Importación de imágenes SVG desde Open Clipart, Wikimedia Commons y otras fuentes en línea
• Origen del objeto seleccionable para escalar y mover numéricamente
• Todas las opciones de alineación en un único cuadro de diálogo
• Edición de degradados en el cuadro de diálogo Relleno y Trazo
• Difuminación de degradados
• Actualización del editor de fuentes SVG
• Flujo de texto alrededor de las formas y relleno de texto
• Práctica operación booleana para dividir trazados
• Barra de herramientas configurable, escala de iconos continua y muchas más opciones de personalización nuevas
• Mejoras en el rendimiento de muchas partes de la interfaz y de muchas funciones diferentes
• Muchas mejoras en la interfaz de usuario
• Numerosas correcciones de fallos y errores en el programa principal de Inkscape y en las extensiones de stock

¿Qué es Inkscape?

Para quien no lo sepa, Inkscape es un editor de gráficos vectoriales de código abierto, similar a programas como Adobe Illustrator, Corel Draw, Freehand o Xara X. Lo que lo hace único es que usa como formato nativo el Scalable Vector Graphics (SVG), un estándar abierto de W3C basado en XML.

En la actualidad, es perfectamente usable para todo tipos de ilustraciones y su potencia está más que demostrada, como podemos ver en este vídeo del Diseño de un logo con degradados, calados y reflejo de Ger Garpe.

La entrada Lanzado Inkscape 1.2, ahora multipágina se publicó primero en KDE Blog.

Cada vez más cerca la publicación final de la distribución de GNU/Linux openSUSE Leap 15.4

La comunidad de openSUSE ha publicado la versión «Release Candidate» o RC de su distribución de GNU/Linux openSUSE Leap 15.4, cuya versión final se publicará a principios de junio de 2022.

Después de que la versión en desarrollo de openSUSE Leap 15.4 pasara todos los tests automáticos de openQA que aseguran y comprueban varias facetas de estabilidad de la distribución de GNU/Linux, se ha publicado esta versión RC.

Esta nueva fase y versión también implica que hay una nueva versión de Leap Micro, un sistema operativo moderno y ligero, ideal para cargas de trabajo virtualizadas y de contenedor de host, que también pasa a su fase Release Candidate.

Esta versión RC de openSUSE Leap 15.4 marca la fecha para la congelación de los paquetes del software que se incluirá en la distribución, que podrás utilizar en servidores, estaciones de trabajo, escritorios y para virtualización y uso de contenedores.

El próximo hito, será la publicación de la versión «Golden Master» o GM de openSUSE Leap 15.4 que se publicará el 27 de mayo de 2022.

Durante la etapa de desarrollo de las versiones de Leap, los colaboradores, los empaquetadores y el equipo de lanzamiento utilizan un método de desarrollo continuo (similar a openSUSE TUmbleweed) que se clasifica en fases en lugar de un solo lanzamiento de hito.

Las snapshots se lanzan con actualizaciones de software de versiones menores una vez que pasan las pruebas automatizadas hasta el lanzamiento final del GM. En ese momento, la distribución cambia de un método de desarrollo continuo a un ciclo de publicaciones puntuales en el que recibe actualizaciones hasta el final de su vida útil (EOL).

Por tanto si ya tienes openSUSE Leap 15.4 probando en tu equipo, recuerda que el comando recomendado para actualizar a esta nueva versión es «zypper dup» hasta que se publique la versión final.

Tienes toda la información de fechas previstas de los próximos lanzamientos en este enlace:

• https://en.opensuse.org/openSUSE:Roadmap

Puedes leer el anuncio oficial:

• https://news.opensuse.org/2022/05/17/leap-reaches-rc-phase/

Sin duda esta nueva versión de la distribución de GNU/Linux openSUSE Leap 15.4, será otro buen ejemplo de estabilidad, ¡para disfrutar tu GNU/Linux sin sobresaltos! en tu portátil, tu servidor, tu máquina virtual, tu Raspberry Pi, …

This week I am talking to Timothy Pearson of Raptor Engineering. He is behind the Talos II and Blackbird boards for IBM POWER9 CPUs. His major claim is creating the first fully owner controlled general purpose computer in a long while. My view of the Talos II and Blackbird systems is that these boards helped to revitalize the open source ecosystem around POWER more than any other efforts (See also: https://peter.czanik.hu/posts/cult-amiga-sgi-workstations-matter/). Most open source developers I talked to say that coding on a remote server is just work. Doing the same on your local workstation adds an important ingredient: passion. This is why the re-introduction of POWER workstations was a very important step: developers started to improve support for POWER also in their free time, not just in their regular working hours. I asked Tim how the idea of creating their POWER board was born, how Covid affected them and also a bit about their future plans.

Raptor Engineering seems to focus on machine vision. How can a company that’s focused on other activities start to develop a mainboard for POWER CPUs?

So to start with, Raptor Engineering’s public facing website was always more of a way to market technologies we’d already developed for internal purposes to the general public. Raptor Engineering is, and always has been, more of a FPGA HDL/firmware/OS level design company focused on providing those services to those that need them. Sometimes we do engage in internal development projects to showcase certain technology capabilities publicly, and one of those was the open source machine vision system you allude to earlier.

More relevant to the current technology offerings, we’ve always had some degree of focus on security and what we now tend to call “owner control”. This was borne out of several long-running research and development projects, where significant investment was made in technologies that could be years, if not decades, from practical application. As a result of this longer term focus, it was realized early on that two issues had to be addressed: something we call “continuance” (the ability to seamlessly move from one generation of technology to another as needed, with no loss of data) and also the data security / privacy aspects of keeping internal R&D results private and out of the hands of potential competition.

Around 2008-2009 we realized that a fully owner controlled system would meet all of these objectives, specifically a system over which we had full control of the firmware, OS, and application layer, a system where we could modify any aspect of its operation independently as required to support the overall objectives. There’s a true story I like to tell, which dates from the early days of the coreboot port efforts on our side to support the AMD K8 systems in use at the time: the proprietary BIOS would not, for some infurating reason, allow a boot without a CMOS battery and a keyboard connected! When spread across supercomputer racks, this was a perfect opportunity to highlight just what owner control actually meant in terms of benefit for maintainance and overall scalability – the rather obvious resulting boot problem could have been solved with a single line of code, if only there had been code available.

Once we had a completely free stack for K8/Family 10h, we continued on with AMD systems until around 2013/2014, when it became clear that AMD would force the Platform Security Processor (an unauditable low-level AMD-controlled black box that presents a severe security risk) on all CPUs going forward. This kicked off a multi-year evaluation of anything and everything that might be able to replace the x86 systems we had in terms of owner control, overall performance, and ease of administration (ecosystem compatibility). Over those years we evaluated everything from ARM to RISC-V to MIPS, and eventually settled on the then-new OpenPOWER systems as the only solution to actually check all of the boxes. The rest, as they say, is history – the nascent computer ODM arm of Raptor Engineering was spun off as Raptor Computing Systems to allow it to grown into the role demanded of it with the Talos II systems it was bringing to market.

Six years ago I first learned about the Talos plans from the Raptor Engineering website. Now all POWER-related activity is on the Raptor Computing website. How are the two related?

As of right now I am involved with both companies, my role at Raptor Computing Systems being that of CTO. Basically I help ensure RCS brings new owner-controlled, blob-free devices to market, and keep fairly close tabs on available silicon and its limitations (mostly centering around blobs) as a result. On the Raptor Engineering side I still provide specialized consulting services at a low level (typically HDL / firmware), as an example you’ll see my name here and there on projects like OpenBMC, LibreSoC, and more recently the Xen hypervisor port for POWER systems that is just spinning up now.

What do you mean by “fully owner controlled”?

An owner-controlled device is best defined as a tool that answers only to its physical owner, i.e. its owner (and only its owner) has full control over every aspect of its operation. If something is mutable on that device, the owner must be able to make those changes to alter its operation without vendor approval or indeed any vendor involvement at all. This is in stark contrast with the standard PC model, where e.g. Intel or AMD are allowed to make changes on the device but the owner is expressly forbidden to change the device’s operation through various means (legal restrictions, lack of source code, vendor-locked cryptographic signing keys, etc.). In our opinion, such devices never really left the control of the vendor, yet somehow the owner is still legally responsible for the data stored on them – to me, this seems like a rather strange arrangement on which to build an entire modern digital economy and infrastructure.

What are the main differences between the Talos II and Blackbird boards?

The Talos II is a high end full EATX server mainboard, dual socket, designed for 24/7 use in a datacenter or workstation type environment. Blackbird is a much smaller uATX single CPU system with more standard consumer-type interfaces (e.g. audio, HDMI, SATA, etc.) available directly on the mainboard.

You mention that Blackbird is consumer focused. It has three Ethernet ports, and support for remote management. Did you also have servers / appliances in mind?

Yes, there is the ability to use the Blackbird for a home NAS or similar appliance. The remote management sort of comes “for free” due to the POWER9 processor being paired with the AST2500 BMC ASIC and OpenBMC, it is more of a baseline POWER9 feature than anything else.

I know that quite a few Linux distribution maintainers now use Talos II workstations. Who else are your typical users?

In general we see the same overall subset of people that would use Linux on x86, with a strong skew toward those concerned about privacy and security and a notable (expected) cutout of the normal “content consumer” market (gamers, streaming service consumers, etc.). This holds true both for individuals and organizations, though the skew is much less notable among organizations simply because organizations are not generally purchasing desktop / server systems for gaming and media consumption!

For quite a few years POWER9 was the best CPU to run syslog-ng. What are the typical software your users are running on your POWER workstations and servers?

For the most part, the standard software you would see on comparable x86 boxes. That’s always been one of our requirements, that using the POWER system be as close to using a standard PC as possible, except the POWER system isn’t putting digital handcuffs on its owner and potentially exposing their data for monetization (or, for that matter, to more nefarious actors).

Covid affected most families and businesses around the world. How Raptor was / is affected?

We were hit hard by the shutdowns and subsequent inflation, in common with most manufacturers across the world. We did have to cancel some of the more ambitions POWER9 systems under development (Condor) as well as take on increased ecosystem maintainance load. Some of that, along with the continuous rise in cost of parts and rolling shortages of components, is reflected in the price increases and long lead times that have occured over the past couple of years.

Could you explain how Condor compares to Talos II and Blackbird?

Condor was a pre-COVID development project to try to create a high end standard ATX (vs. EATX) desktop board with OpenCAPI brought out to the appropriate connector. With COVID shutdowns, industry adoption of CXL, and more importantly POWER10 requiring closed source binaries, we didn’t see a path to actually bring the product to market post-COVID. The completed designs are sitting in our archives, but no hardware was manufactured.

The latest x86 CPUs now beat POWER9 in many use cases. Which is no wonder, these CPUs are four years old now. Is there something where POWER9 still has an advantage?

Absolutely! POWER9 still does what we originally intended it to do – it gives reasonable performance on a stable, standardized ecosystem, in a familiar PC-style form factor, using standard PC components, while providing full owner control. As a secure computing platform, both on server and desktop, it simply cannot be beat – there is literally nothing else on the market that is both 100% blob free and can be used as a daily driver for basically every task that a Linux x86 machine can be used for.

For example, I’m responding to this interview using a POWER9 workstation with hundreds of Chromium tabs open, media running, Libreoffice in the background, and am even compiling some software. If you didn’t tell me it was a POWER system, I wouldn’t be able to easily tell just from using it, yet at the same time it’s not restricting what I can do with it, attempting to monetize my data, or otherwise waiting for commands from a potentially hostile (at least to my interests) third party.

The other major selling point is that the ISA is both open and standardized. The standardization means that I could migrate this system as-is – no reinstallation – to anything that is POWER ISA 3.0 compliant, which is a huge advantage only available for the “big three” architectures (x86, SBSA ARM, and OpenPOWER). That said, being an open ISA, anyone is also free to create a new compliant CPU if they want to or need to. This neatly avoids the entire problem with x86 and ARM, where various technologies (ME, PSP, TrustZone w/ bootloader locking) could be (and eventually were) unilaterally forced onto all users regardless of the grave issues they introduce for specific use cases.

Also interesting is how the OpenPOWER ISA is governed – a neutral entity (the OpenPOWER Foundation) controls the standards documents that implementations must adhere to, and anyone is free to propose an extension to the ISA. If accepted, it becomes part of the ISA compliance requirements for a future version, and the requisite IP rights are transferred to the Foundation such that anyone is still free to implement that instruction per the specification without needing to go back and license with the entity that proposed the extension. This is a great model in my mind, it should allow the best of both worlds going forward. The standardization and compliance requirements mean we should see the same level of binary support normally expected on x86, while the extension proposal mechanism allows the ISA to morph and adapt in a backward-compatibile way in response to external needs.

The POWER 10 CPUs from IBM are manufactured with the latest technologies allowing higher performance with lower power consumption. Do you have any plans to have a new board with POWER 10 support?

At this time we do not have plans to create a POWER10 system. The reasoning behind this is that somehow, during the COVID19 shutdowns and subsequent Global Foundries issues, IBM ended up placing two binary blobs into the POWER10 system. One is loaded onto the Microsemi OMI to DDR4 memory bridge chip, and the other is loaded into what appears to be a Synopsis IP block located on the POWER10 die itself. Combined, they mean that all data flowing into and out of the POWER10 cores over any kind of high speed interface is subject to inspection and/or modfication by a binary firmware component that is completely unauditable – basically a worst-case scenario that is strangely reminiscent of the Intel Management Engine / AMD Platorm Security Processor (both have a similar level of access to all data on the system, and both are required to use the processor). Our general position is that if IBM considered these components potentially unstable enough to require future firmware updates, the firmware must be open source so that entities and owners outside of IBM can also modify those components to fit their specific needs.

Were IBM to either open source the firmware or produce a device that did not require / allow mutable firmware components in those locations, we would likely reconsider this decision. For now, we continue to work in the background on potential pathways off of POWER9 that retain full compatibility with the existing POWER9 software ecosystem, so stay tuned!

Does “potential pathways off of POWER9” have something to do with the LibreSoc project?

We’re going to remain a bit coy on this, but LibreSoC is definitely one project that would fit that requirement for at least low-end devices. In fact, you can see some of my fingerprints in the LibreSoC GIT history…

Photo credits:

Copyright: Vikings GmbH License: CC BY 4.0

As our usual readers know, the YaST team is lately involved in many projects not limited to YaST itself. So let’s take a look to some of the more interesting things that happened in those projects in the latest couple of weeks.

Improvements in YaST

As you can imagine, a significant part of our daily work is invested in polishing the versions of YaST that will be soon published as part of SUSE Linux Enterprise 15-SP4 and openSUSE Leap 15.4, whose first Release Candidate version is already available.

That includes, among many other things, improving the behavior of yast2-kdump in systems with Firmware-Assisted Dump (fadump) or adding a bit of extra information to the installation progress screen that we recently simplified.

YaST in a Box

So the present of YaST is in good hands… but we also want to make sure YaST keeps being useful in the future. And the future of Linux seems to be containerized applications and workloads. So we decided to investigate a bit whether it would be possible to configure a system using YaST… but with YaST running in a container instead of directly on the system being configured.

And turns out it’s possible and we actually managed to run several YaST modules with different levels of success. Take a look to this repository at Github including not only useful scripts and Docker configurations, but also a nice report explaining what we have achieved so far and what steps could we take in the future if we want to go further into making YaST a containerizable tool.

Evolution of D-Installer

Running into containers may be the future for YaST as a configuration tool (or not!). But we are also curious about what the future will bring for YaST as an installer. In that regard, you know we have been toying with the idea of using the existing YaST components as back-end for a new installer based on D-Bus temporarily nicknamed D-Installer. And, as you would expect, we also have news to share about D-Installer.

On the one hand, we used the recently implemented infrastructure for bi-directional communication (which allows the back-end of the installer to ask questions to the user when some input is needed) to handle some situations that could happen while analyzing the existing storage setup of the system. On the other hand, we added the possibility of modifying the D-Installer configuration via boot arguments, with the option to get some parts of that configuration from a given URL.

See you Soon!

If you want to get more first-hand information about recent (Auto)YaST changes, about D-Installer development or any other of the topics we usually cover in this blog, bear in mind openSUSE Conference 2022 is just around the corner and a big part of the YaST Team will be there presenting these and other topics. We hope to see as many of you there in person. But don’t worry much if you cannot attend, we will keep blogging and will stay reachable at all the usual channels. So stay tuned for more news… and more fun!

The openSUSE Project has entered the Release Candidate phase for the next minor release version of the openSUSE Leap distribution.

The upcoming release of Leap 15.4 transitioned from its Beta phase to Release Candidate phase after Build 230.2 passed openQA quality assurance testing.

“Test results look pretty solid as you’d expect from RC,” wrote release manager Lubos Kocman in an email on the openSUSE Factory mailing list yesterday. “My original ETA was Wednesday, but we managed to get (the) build finished and tested sooner.”

The new phase also changes the new offering of Leap Micro, which is a modern lightweight operating system ideal for host-container and virtualized workloads, into its Release Candidate phase.

The RC signals the package freeze for software that will make it into the distribution, which is used on servers, workstations, desktops and for virtualization and container use.

The Leap 15.4 Gold Master (GM) build is currently scheduled for May 27, according to Kocman, which is expected to give time for SUSE Linux Enterprise changes and its Services Pack 4 GM acceptance; this will allow for the pulling in of any translation updates and finish pending tasks such as another security audit.

Kocman recommends Beta and RC testers use the “zypper dup” command in the terminal when upgrading to the General Availability (GA) once it’s released.

During the development stage of Leap versions, contributors, packagers and the release team use a rolling development method that are categorized into phases rather than a single milestone release; snapshots are released with minor version software updates once passing automated testing until the final release of the GM. At that point, the distribution shifts from a rolling development method into a supported release cycle where it receives updates until its End of Life (EOL). View the openSUSE Roadmap for more details on public availability of the release.

The community is supportive and engages with people who use older versions of Leap through community channels like the mailing lists, Matrix, Discord, Telegram, and Facebook. Visit the wiki to find out more about openSUSE community’s communication channels.

La noticia es algo vieja pero creo que suficientemente interesante para tener cabida en el blog. Y es que desde el 10 de mayo KDE Connect está disponble para iOS, el sistema operativo de los iPhone. Una buena noticias para estos usuarios y para la Comunidad KDE ya que acerca a los primeros al Software Libre.

KDE Connect disponible para iOS

Tener una aplicación única y sobresaliente en muchos aspectos es muy importante para poder demostrar que tu ecosistema funciona. En el mundo KDE esto está sobradamente demostrado con aplicaciones como Dolphin, Kdenlive, Okular o Kate, por citar unas pocas de un club selecto que destacan por sus funconalidades, versatiblidad, sencillez y potencia…. Y dentro de este grupo, sin duda alguna, podríamos incorporar KDE Connect.

Pues bien, a esta gran aplicación se le acaba de unir un complemento para los usuarios del sistema iOS de los teléfonos iPhone, concretamente por fin tendrán su cliente para poder conectar su smartphone con el escritorio Plasma.

Más información y descarga: APP Store

¿Qué es KDE Connect?

Por si alguien no lo sabe, KDE Connect es un proyecto de Albert Vaca (que se inició dentro del programa GSoC y se presentó en Akademy-es 2013 de Bilbao) con el que la comunicación entre tu smartphone o teléfono móvil Android y tu ordenador con KDE es casi perfecta.

De hecho con KDE Connect se puede, entre otras cosas.

• Notificar llamadas
• Notificar SMS
• Indicar el estado de la batería del móvil
• Sincronizar portapapeles
• Control Multimedia (audio/vídeo)
• Notificaciones de pings
• Notificar todo tipo de mensajes del dispositivo móvil
• Transferir archivos
• Transferir enlaces web

La entrada KDE Connect está disponible para iOS se publicó primero en KDE Blog.

I’m not superstitious, so I never really cared about black cats, Friday the 13th, and other signs of (imagined) trouble. Last Friday (which was the 13th) I had an article printed in a leading computer magazine in Hungary, and I gave my first IRL talk at a conference in well over two years. Best of all, I also met many people, some for the first time in real life.

Free Software Conference: sudo talk

Last Friday, I gave a talk at the Free Software Conference in Szeged. It was my first IRL conference talk in well over two years. I gave my previous non-virtual talk in Pasadena at SCALE; after that, I arrived Hungary only a day before flights between the EU and the US were shut down due to Covid.

I must admit that I could not finish presenting all my slides. I practiced my talk many times, so in the end, I could fit my talk into my time slot. However, I practiced the talk by talking to my screen. That gives no feedback, which is one of the reasons I hate virtual talks. At the event, I could see my audience and read from their faces when something was really interesting, or something was difficult to follow. In both cases, I improvised and added some more details. In the end, I had to skip three of my slides, including the summary. Luckily, all important slides were already shown. The talk was short, so the summary was probably not really missing. Once my talk was over, many people came to me for stickers, and to explain which of the features they learned about they plan to implement once they are back home.

My talk was in Hungarian. Everything about sudo is in English in my head. I had to do some simultaneous interpreting from English to Hungarian, at least when I started practicing my talk. I gave an earlier version of this talk at FOSDEM in English. So, if you want to learn about some of the latest sudo features in English, you can watch it at the FOSDEM website at https://fosdem.org/2022/schedule/event/security_sudo/.

ComputerWorld: syslog-ng article

Once upon a time, I learned journalism in Hungarian. I even wrote a couple of articles in Hungarian half a decade ago. However, I’ve been writing only in English ever since. The syslog-ng blog, the sudo blog, and even my own personal blog where you read this, are all in English. Other than a few chats and e-mails, all my communication is in English.

Last week the Hungarian edition of ComputerWorld prepared with a few extra pages for the Free Software Conference. It also featured an article I wrote about some little known facts about syslog-ng. Writing in Hungarian was quite a challenge, just like talking in Hungarian. I tried to find a balance in the use of English words. Some people use English expressions for almost everything, so just a few words are actually in Hungarian. I hate the other extreme even more: when all words are in Hungarian, and I need to guess what the author is trying to say. I hope I found an enjoyable compromise.

I must admit, it was a great feeling to see my article printed. :-)

Meeting people: Turris, Fedora community

Last Friday I also met many people for the first time in person, or for the first time in person in a long while. I am a member of the Hungarian Fedora community. We met regularly earlier but not any more. I keep in touch with individual members over the Internet, but in Szeged, I could meet some of them in person and have some longer discussions.

If you checked the website of the conference, you could see that it was the first ever international version of the event. When I learned that the conference is not just for Hungarians but for the V4 countries as well, I reached out to the Turris guys. Their booth was super busy during the conference, but luckily, I had a chance to chat with them a bit. Two of their talks were at the same time as my talk, but I could listen to their third talk. It was really nice: I learned about the history of the project.

As you can see, my Friday the 13th was a fantastic day. I knock on wood hoping that Friday the 13th stays a lucky day. OK, just kidding :-)

En GNU/Linux puedes programar tus tareas cron de diferentes maneras

Puede que le sorprenda que la versión de cron que se ejecuta en su servidor hoy en día es en gran medida compatible con la especificación crontab escrita en la década de 1970.

Una desventaja de esta cuidadosa compatibilidad con versiones anteriores es que los trabajos, incluso en el mismo servidor, se pueden crear y programar de manera diferente.

Este artículo, es una traducción/adaptación de un artículo en inglés escrito por Shane Harter que puedes encontrar en este enlace:

• https://blog.cronitor.io/5-places-cron-jobs-live-in-linux-4913a57b7c1b

1.- El crontab de usuario

En sistemas GNU/Linux, cada usuario tiene su propio crontab que puede ver y actualizar con el comando crontab. Para ver un listado de las tareas cron de tu usuario, puedes ejecutar:

crontab -l

El crontab de cada usuario es el lugar más fácil para añadir un nuevo trabajo para que se ejecute de manera automática cuando quiera, por lo que es el que se usa de manera frecuente y es el primer lugar en el que buscar cuando no se está seguro de cómo se ha programado una tarea.

Para editar una tarea crontab y añadir y/o modificar nuevas tareas puedes hacerlo mediante:

crontab -e

En los «logs» o registros de los sistemas GNU/Linux queda registrados, además de muchos otros eventos, qué tareas crontab se han realizado y de qué usuario del sistema son.

2.- El crontab del usuario root

Como cualquier otro usuario del sistema, también el usuario «root» de GNU/Linux puede tener establecidos sus propias tareas crontab.

Puedes iniciar sesión como «root» y listar si hay tareas de cron con el comando que hemos visto anteriormente.

3.- El archivo crontab del sistema

La forma original y que todavía se sigue utilizando para programar trabajos cron en todo el sistema, es agregando entradas en el archivo: /etc/crontab.

Para escribir en /etc/crontab requiere privilegios de usuario «root» y los trabajos programados se pueden ejecutar como cualquier usuario del sistema.

Si la primera palabra en su comando de trabajo coincide con una cuenta de usuario del sistema, el comando se ejecuta como ese usuario. Si no se especifica ningún usuario, se ejecuta como root.

Aquí el usuario tux realizará la siguiente tarea cron:

* 0 * * * tux /var/scripts/backup.sh

4.- Un archivo crontab en el propio directorio /etc/cron.d

En algún momento los desarrolladores se dieron cuenta de que era una mala práctica tener un único crontab en todo el sistema que pudiera ser cambiado por instaladores y herramientas automatizadas y nació el directorio /etc/cron.d/.

Los trabajos se programan usando /etc/cron.d copiando o creando un enlace simbólico a un archivo crontab. Al igual que los trabajos programados en /etc/crontab, la primera palabra del comando puede especificar opcionalmente el usuario para ejecutar el trabajo.

5.- Un script o comando en /etc/cron.hourly, /etc/cron.daily, etc

Cuando la programación de una tarea al detalle es menos importante que la simple frecuencia, se pueden crear trabajos cron copiando o enlazando un script en los directorios:

• /etc/cron.hourly – realiza tareas de a cada hora
• /etc/cron.daily – realiza tareas de a cada día
• /etc/cron.weekly – realiza tareas de a cada semana
• /etc/cron.monthly – realiza tareas de a cada mes

Bola extra

Como información extra, cuando los crontabs de usuarios individuales se editan mediante el comando crontab -e que hemos visto anteriormente, los archivos crontab se almacenan en /var/spool/cron.

No es buena idea editar esos archivos directamente y, en su lugar, es recomendable ejecutar crontab -e como el usuario que ejecutará el trabajo programado.

Si editas esos archivos en /var/spool/cron directamente, perderás el beneficio de la verificación de sintaxis que proporciona crontab -e y es posible que tu distribución de GNU/Linux no detecte los cambios realizados sin una recarga explícita del demonio cron.

¿Te ha resultado interesante la lectura? No hemos entrado al detalle de cómo crear tareas cron, algo que por la red se puede encontrar sin mucho problema, pero sí hemos visto donde podemos programar nuestras tareas cron.

Si aprendiste algo nuevo, o si hay algo que sabes que no se ha comentado aquí y que complementa lo escrito, usa los comentarios del blog para compartir lo que quieras.

Hoy toca hacer más promoción del evento presencial que se va a celebrar el próximo 18 y 19 de mayo en la Universidad Jaume I de Castellón. Se trata de dar a conocer el programa de Ujilliurex 2022 un evento que une educación, Software Libre y Conocimiento Compartido a parte iguales.

Programa de Ujilliurex 2022 #ujilliurex

Aunque lo anuncié hace poco quiero seguir haciendo promoción de este evento que ya vuelve en la forma tradicional, es decir, presencial en el Aula Magna (HA1012AA) de la Facultad de Ciencias Humanas y Sociales de la Universidad Jaume I, conocida por casi todos como UJI.

Con14 ponencias tiene como principal objetivo difundir el uso y manejo de las TIC en la distribución LliureX entre la comunidad educativa (universitaria y no universitaria; infantil, primaria, secundaria y formación profesional).

Pero no me enrollo más y comparto con vosotros el listado de ponencias que podéis encontrar en su programa y que en mi humilde opinión dan una buena muestra de las muchas cosas que podemos hacer con nuestro alumnado, la tecnología y el Software Libre.

Miércoles 18 de mayo

• 17:00 La Competencia Digital Docente, análisis críTICo (seguimos sentando las bases y sin pisar la realidad) por Juan Francisco Álvarez Herrero
• 18:00  La competencia digital de los estudiantes en el contexto de la educación superior por Anna Sánchez-Caballé
• 19:15 Digitalización de la FP en la nube por David Montalva Furió
• 20:00 La importancia del código abierto en la CDD por Tàfol Nebot Gómez
• 20:15 Modelo de centro con Proxmox en un pequeño centro de secundaria por Eduardo Millán Martínez

Miércoles 18 de mayo

• 16:30 ASKER, tu generado de preguntas para Moodle por Baltasar Ortega Bort
• 16:50 Accesibilidad para todos por Juan Manuel Navarro Máñez
• 17:10 El ámbito de las TIC de la Subdirección General de Formación del Profesorado por Ignasi Climent Mateu
• 17:30 Plan Digital de Centro por Vicent Part Julio
• 19:00 Markdown y Apuntes por Angel Berlanas Vicente
• 19:200 Experiencia en la transformación de un centro educativo a distancia a Microsoft(CDC) desde el punto de vista docente por Piedad Soriano Montiel
• 19:40 I love Ruby: Scripting feliz! por David Vargas Ruiz
• 20:00 Casa domótica educativa por Jordi Mayné Grau
• 20:15 Uso de H5P19 por Tamara Expósito Ponce

¿Qué os parece el programa? ¿tenía razón? Ya lo sabéis, ayudad al éxito de este evento con vuestra difusión: Ujilliurex se lo merece.

La entrada Programa de Ujilliurex 2022 #ujilliurex se publicó primero en KDE Blog.

Zabbix Server 6.0 with container in GCP 安裝小記