openSUSE Tumbleweed – Review of the week 2020/31

Dear Tumbleweed users and hackers,

Week 31 has seen a steady flow of snapshots. The biggest snapshot was 0721, for which we had to do a full rebuild due to changes in the krb5 package, that moved some files around. In order for all packages to keep up with this change, the full rebuild was needed. The week in total has seen 7 snapshots being published (0721, 0724, 0726, 0727, 0728, 0729 and 0730)

The changes included in those snapshots were:

  • krb5 file system layout changes (moved to default locations)
  • Mesa 20.1.3 & 20.1.4
  • NetworkManager 1.26.0
  • Flatpak 1.8.1
  • Python3 package was renamed to python38, allowing for further parallel packages like python39
  • sudo 1.9.2
  • KDE Plasma 5.19.4
  • Mozilla Firefox 79.0
  • Nano 5.0

The changes currently in stagings are around the topics of:

  • grub2 to address Boothole issues (will come with a new signing key for grub/kernel/shim)
  • GCC 10.2
  • LibreOffice 7.0rc2
  • Change of /tmp to tmpfs
  • openSSL 3.0
  • RPM changes: %{_libexecdir} is being changed to /usr/libexec. This exposes quite a lot of packages that abuse %{_libexecdir} and fail to build. Additionally, the payload compression is being changed to zstd

openSUSE 15.1 to 15.2 upgrade notes

In a previous article I showed how to upgrade a distro using zypper, but after the first reboot some issue might always happen, that’s why I collected all the changes and the tweaks I applied switching from openSUSE 15.1 to 15.2.

¿Cómo convertirse en colaborador de #openSUSE?

¿Estás pensando en colaborar de alguna manera con openSUSE? Quizás esta es una buena manera de empezar

¿Tienes que ser un desarrollador experto para contribuir en un proyecto de código abierto como es openSUSE?

La respuesta rápida: no. Más bien lo contrario. Cuando te unes a una comunidad como openSUSE tienes la oportunidad de aprender desde un nivel de principiante hasta un nivel más avanzado.

Este artículo es una traducción/adaptación del original escrito por Bdekany para la web de SUSE y que también puedes leer en inglés y en francés.

A la hora de empezar a contribuir con código en la comunidad de openSUSE, sin duda la mejor manera de hacerlo es openSUSE Factory. El lugar donde se compila todo el software que llegará a los repositorios de openSUSE.

Pero no solo eso, en el servicio de build.opensuse.org además también puedes compilar tu propio código, ya que permite repositorios privados, no solo para openSUSE, si no también “empaquetarlo” para otras distribuciones (Debian, Fedora, etc) ¿No es maravilloso?

Cada paquete disponible en la distribución openSUSE, pasa por Factory. Su integración contínua (CI) comprueba todo el código enviado por los equipos de desarrollo utilizando varias máquinas virtuales para compilar el código para distintas arquitecturas.

Sí, puedes tener el código disponible desde el clásico x86 hasta para arquitecturas ARM Soc y para distintas distribuciones y versiones de sistemas operativos.

Para este ejemplo de acercamiento a cómo contribuir con openSUSE mediante Factory, echemos un vistazo al paquete iftop, una utilidad para la línea de comandos que muestra el tráfico de nuestra red.

Este paquete está en un estado de fallo, pero funciona perfectamente en versiones previas de openSUSE. ¿Por qué? Echemos un vistazo e investiguemos…

Los errores de compilación son visibles echando un vistazo a los registros o “logs” del proceso de compilación, que podremos consultar en la interfaz web de build.opensuse.org

openSUSE es un proyecto en perpetuo movimiento y mejora. Cada nueva publicación lleva más allá el nivel de seguridad y la optimización del sistema y de las herramientas.

Aquí se puede ver un ejemplo del comportamiento de la nueva versión 10 del compilador GCC. El código fuente escrito en lenguaje C donde la variable no está explícitamente declarada, provoca un error. Más información al respecto en este enlace.

Echando un vistazo al error, y teniendo en cuenta las nuevas reglas de GCC10, las declaraciones de variables implícitas están prohibidas. Por lo que hay que utilizar una declaración externa, para que GCC entienda que eso no es un problema de la memoria o una vulnerabilidad.

Así que ya sea mediante la interfaz web o la herramienta de la línea de comandos, puedes crear una copia personal del repositorio, clonarlo en tu equipo, y en esa copia local crear tu parche y enviarlo para que sea compilado de nuevo.

Una vez realizado el proceso, si la compilación está libre de errores y todo ha salido bien, puedes enviar una petición de “merge” al repositorio oficial.

Será revisado por el mantenedor y si lo ve correcto lo aceptará. Y tu parche en un paquete de openSUSE estará disponible para toda la comunidad que lo instalará cuando actualice su sistema y el paquete actualizado llegue a sus repositorios.

El proceso de trabajo, a la hora de clonar el repositorio y trabajar con esta herramienta está explicado con todo detalle en la wiki de openSUSE.

Como ves, no hace falta ser un desarrollador experto, pero en el caso de querer contribuir con código, sí son necesarias ciertas nociones básicas.

A partir de ahí puedes ir aprendiendo más y más, consultar las listas de correo para resolver dudas, participar en los equipos de desarrollo de openSUSE o quizás llegar a encargarte mantener un paquete y ponerlo a disposición de toda la comunidad de openSUSE.

Si quieres, o importante es dar tu primer paso, después poco a poco ir aprendiendo…

Jul 30th, 2020

Actualizado Lliurex 19, ahora con Jitsi integrado

Aunque prometí ir hablando más de Liurex ahora que se había pasado al escritorio Plasma de la Comunidad KDE lo cierto es que no cumplí mi promesa. Es hora de enmendar el error y hablar un poco de él. Y es que este julio del 2020 ha sido actualizado Lliurex 19 con interesantes novedades como la integración con Jitsi.

Actualizado Lliurex 19, ahora con Jitsi integrado

En julio de 2019 Lliurex, la veterana distribución GNU/Linux de la Comunidad Valenciana, dio el paso y cambió de entorno de escritorio a Plasma de la Comunidad KDE.

Parafraseando a Neil Armstrong, fue un pequeño paso para una distribución pero un gran paso para la Comunidad KDE, que de repente tendría una gran masa de potenciales usuarios.

De esta forma decidimos aprovechando el lanzamiento realizar un podcast y hablar con algunos de sus desarrolladores, en un más que interesante capítulo de los podcast de KDE España que inauguraba la sexta temporada.

Ha pasado un curso escolar, que por cierto ha sido bastante movidito, y los desarrolladores han tenido que ir adaptando el mismo a las nuevas y futuras necesidades de los docentes y alumnos como servicios de webconferencia integrados o un instalador de LLiurex en Windows, algo que puede ser útil en determinados casos (como cuando no se tiene soporte técnico presencial y se quiere utilizar Liurex).

Actualizado Lliurex 19, ahora con Jitsi integrado
lliurex

Nueva actualización de lliurex 19.07 que incluye:

  • Servicio de videoconferencias dentro del centro con Jitsi
  • Nuevo instalador de LliureX para Windows
  • Nueva versión de lliurex para FP
  • Revisión y mejora de PRINTA, la aplicación para gestionar las impresiones en un Centro.
  • Nueva página de inicio
  • Cloudbook, un generador de contenidos digitales abiertos que tiene muy buena punta.

Además, se han actualizado aplicaciones clave como Firefox o LibreOffice, con la consecuente mejora en productividad, estabilidad y con las nuevas funcionalidades que estas aplicaciones proporcionan.

Además, en esta ocasión, los desarrolladores han elaborado un vídeo donde explican estas y más novedades de esta nueva versión.

Más información: Lliurex

oneAPI compatibility with all openSUSE

As leader of the openSUSE Innovator initiative, openSUSE member and official oneAPI innovator, I tested the new release of the tool on openSUSE Leap 15.1, 15.2 and Tumbleweed. With the total success of the work, I made available in the SDB an article on how to install this solution on the openSUSE platform. More information here: https://en.opensuse.org/SDB:Install_oneAPI.

oneAPI is an Unified, Standards-Based Programming Model. Modern workload diversity necessitates the need for architectural diversity; no single architecture is best for every workload. XPUs, including CPUs, GPUs, FPGAs, and other accelerators, are required to extract high performance.

This technology have the tools needed to deploy applications and solutions across these architectures. Its set of complementary toolkits—a base kit and specialty add-ons—simplify programming and help developers improve efficiency and innovation. The core Intel oneAPI DPC++ Compiler and libraries implement the oneAPI industry specifications available at https://www.oneapi.com/open-source/.

Some features

DPC++: Data Parallel C++ (DPC++) is an open, standards-based evolution of ISO C++ that incorporates Khronos SYCL and community extensions to simplify data parallel programming.

CUDA Source Code Migration: The DPC++ Compatibility Tool is a migration engine that transforms CUDA code into a standards-based DPC++ code.

AI: Designed for end-to-end machine learning and data science pipelines, these toolkits are comprised of optimized Python libraries and high-performance, deep learning frameworks and tools based on oneAPI libraries.

Libraries : Powerful libraries—including deep learning, math, and video and media processing-are preoptimized for domain-specific functions and custom coded to accelerate compute-intense workloads.

For more information: https://software.intel.com/content/www/us/en/develop/tools/oneapi.html

Jul 29th, 2020

GPT-3 : Aparentemente a inteligência mais avançada criada pelo homem.

Nas últimas semanas a OpenAI (organização sem fins lucrativos) anunciou ao mundo o desenvolvimento do GPT-3, um grande passo evolutivo no contexto da Inteligência Artificial (se você não ouviu falar, irá em breve e muito). Uma tecnologia de interpretação de linguagem pode gerar texto, músicas, literários e muito mais. Pois apresenta um modelo de rede neural baseado em autoaprendizado por bilhões de conexões.

Esta inteligência artificial embrionária, parece ser o futuro assustador para alguns e admirável para outros. Baseado na aprendizagem de linguagem, a tecnologia aprendeu não somente programar, aprendeu inglês utilizando o processamento de muitos terabytes de dados. Resumidamente aprendeu e dominou informações disponíveis na internet (música, html, inglês etc). Com apenas alguns parágrafos de amostragem, foi possível gerar um texto no estilo poeta modernista norte-americano Wallace Stevens.

O que me chamou a atenção é como a inteligência consegue lidar com a questão semântica em textos. A arquitetura não é novidade, e sim seu tamanho. Pois o BERT LARGE (modelo de NLP) da Google tinha 340 milhões de parâmetros, a GPT-3 tem 174 Bilhões de parâmetros.

Na minha opinião, esta tecnologia é genial, mas estamos superestimando as máquinas e subestimando nossa inteligência. Então não podemos deixar este fenômeno fazer os talentos desistirem de estudar e se dedicar. Pois isto acarreta a desistência de novos talentos na área, e só aumentará a escassez no mercado.

Escrever sistema/solução não é criar linhas de código, e sim entender a demanda, os requisitos, público-alvo entre outros. O principal objetivo foi criar uma inteligência artificiai que “sirva a humanidade em qualquer aspecto”. Logo, esta AI consegue produzir textos realistas sobre qualquer tema solicitado. Em testes reais, humanos foram enganados acreditando que o texto da AI foi escrito por humano. Mas isto não significa que um humano não elabora um texto superior.

O ser humano é muito mais que um ser vivo inteligente. É um ser criativo, sentimental, espiritual e outros. E nenhuma máquina vai me substituir tão fácil, o meu espírito competitivo não permite. Mas concordo que tecnologias como esta, será uma ferramenta impressionável (meu braço direito). Veja abaixo um exemplo da tecnologia em atuação:

Na minha particular opinião o GPT-3, é como o mouse e a interface gráfica criada pela Xerox, ou seja, será inspiração para uma nova era de produtos para AI.

Mais informações: https://openai.com/

Webinar Zimbra : Mindset untuk Team IT

Sejak beberapa hari terakhir saya mondar-mandir koordinasi dengan team untuk persiapan webinar mengenai Implementasi Zimbra. Saya kebagian jatah mengisi sesi “Introduction to Excellent” dan screenshot yang saya tampilkan ini adalah salah satu bagian slide yang saya presentasikan tadi siang.

Untuk materi slide lainnya akan coba saya upload secara bertahap dalam kesempatan berikutnya.

Saya memerlukan waktu beberapa hari menyesuaikan materi presentasi agar selaras dengan keseluruhan tema, merapikan screenshot, mengarang note untuk setiap slide yang disampaikan dan melakukan ujicoba presentasi apakah waktunya terlewat atau tidak, apakah ada yang kurang jelas dan apakah ada informasi yang perlu diperbaiki.

Sebelum membangun Excellent, saya bekerja sebagai staff IT di perusahaan. Ada beberapa mindset yang saat itu saya pegang namun setelah sekian waktu, saya melihat bahwa mindset tersebut perlu disesuaikan.

Misalnya yang pertama soal Good Admin is Everything. Ada pemikiran bahwa Admin yang bagus adalah Admin yang bisa segalanya. Timbul kesan, jika pekerjaan diserahkan pada vendor, lantas apa fungsi kita sebagai team IT.

Padahal ukurannya adalah keberhasilan implementasi. Pada result atau hasil akhir. Jika kita memiliki berbagai pengetahuan teknis tapi hasil akhir ternyata tidak berjalan sesuai harapan, tetap saja kita dianggap sebagai team IT yang gagal. Perlu diingat, vendor itu adalah partner, bukan musuh. Akan jauh lebih baik jika kerjasama yang terjalin memberikan dorongan pada kelancaran proses implementasi. Kita sebagai team internal bisa banyak belajar, menambah pengetahuan sekaligus bisa fokus pada aspek monitoring dan supervisi.

Ada kalimat, “Serahkan suatu pekerjaan pada ahlinya, jadi jika hendak melakukan implementasi Zimbra dan merasa ada banyak hal yang harus dilakukan dan khawatir tidak kuat, biar Excellent saja yang melakukannya 🙂 . Nanti prestasi implementasi tetap merupakan prestasi team IT yang mampu menjamin keberhasilan berjalannya pekerjaan, bukan prestasi vendor seperti Excellent.

Yang kedua mengenai Budget. “Jika menggunakan Zimbra Network Edition, berarti harus keluar biaya?” Iya, karena memang ada kebutuhan biaya lisensi.

“Wah kalau keluar biaya, sayang dong, kan pakai open source juga bisa”.

Benar bisa, tapi apakah sesuai dengan kebutuhan perusahaan?

Tidak semua pengeluaran uang itu pemborosan. Investment worth the risk. Jika kita tidak keluar biaya sama sekali tapi data email hilang atau perusahaan terkena penipuan hingga rugi ratusan juta atau miliaran rupiah; tender gagal terkirim karena informasinya terhambat di komunikasi email; itu namanya bukan cerdas melainkan celaka. Siapa yang salah? Ya kita sebagai IT yang merasa uang yang dikeluarkan adalah uang milik pribadi.

Jadi, serba berhemat untuk segala hal tidak selalu benar. Melakukan pengeluaran biaya untuk budget keperluan tertentu juga tidak selalu salah. Yang salah itu jika mengeluarkan uang bukan untuk keperluannya. Jika pengeluaran uang untuk kebaikan perusahaan dan untuk mendukung kelancaran operasional perusahaan, itu justru prestasi, karena bisa mencegah kerugian dan meningkatkan peluang keberhasilan.

Yang terakhir soal mindset, “Perusahaan belum butuh karena atasan atau pimpinan atau user juga belum minta”. Sebagai IT kita seharusnya one step ahead. Satu langkah didepan. Jika perlu 10 langkah didepan. Sebelum pimpinan atau atasan minta, kita sudah melakukan riset. Sudah ada usaha. Jangan seperti paku, saat digetok baru berjalan.

Bisa jadi pimpinan belum minta karena belum tahu atau belum terbayang pentingnya feature tersebut.

Misalnya, “buat apa pakai digital signature?”. Oh itu penting untuk memastikan identitas rekanan yang berkomunikasi dan mencegah pemalsuan identitas.

“Mengapa pakai 2 factor?”, agar email account lebih aman.

“Mengapa pakai delegated admin?”, supaya ada pembagian wewenang yang jelas.

Jika kita mau berusaha memperbaiki diri dan kualitas, nanti ada perbedaan. Ada jarak dari kondisi sebelumnya. Berbeda jika kita statis dan menikmati keamanan semu, nanti baru sadar saat sudah terlambat atau saat pimpinan tahu dari pihak lain.

Universal mounter/unmounter Original – Service menu para KDE (15)

Le estoy cogiendo el gustillo a esto de los Service Menu para KDE. Hoy me congratula compartir con vosotros Universal mounter/unmounter Original, un pequeño complemento que nos ayuda, como su nombre indica, a montar y desmontar archivos en nuestro sistema.

Universal mounter/unmounter Original – Service menu para KDE (15)

Como los seguidores habituales del blog ya serán conocedores, la idea de los Service Menu es simple: añadir al botón derecho de Plasma en Dolphin la opción de realizar cualquier acción que se nos ocurra.

Hoy me complace presentar Universal mounter/unmounter Original, una creación de Shevchuk que nos permite montar y desmontar cualquier fichero montable con un simple click.

Universal mounter/unmounter Original - Service menu para KDE (15)

Hay que insistir que al programador de este Universal mounter/unmounter Original le encantará que le deis me gusta en la KDE Store y que le comentéis como os funciona. Os recuerdo que ayudar al desarrollo del Software Libre también se hace simplemente dando las gracias, ayuda mucho más de lo que os podéis imaginar, recordad la campaña I love Free Software Day 2017 de la Free Software Foundation donde se nos recordaba esta forma tan sencilla de colaborar con el gran proyecto del Software Libre y que en el blog dedicamos un artículo.

Más información: KDE Store

¿Qué son los Dolphin Service Menu?

La personalización de KDE y Plasma está más que demostrada y prueba de ello son los Dolphin Service Menu, que no son más que la posibilidad de disponer un menú auxiliar en el gestor de archivos Dophin o en Konqueror que se activa con el botón derecho del ratón.
Con ellos tendremos nuevas acciones como:

Y muchos más como hemos explicado en varias ocasiones en el blog. Puedes encontrar estos servicios se pueden encontrar en la sección Dolphin Service Menu en la Store de KDE.

Membersihkan Snapshot yang tertinggal

Pada dasarnya Snapshot yang dibuat oleh Snapper akan otomatis dihapus oleh snapper-cleanup.service jika sudah waktunya terhapus sesuai dengan konfigurasi yang ada di /etc/snapper/configs (atau dengan perintah su -c "snapper -c root get-config"). Namun adakalanya Snapper gagal menghapus satu atau beberapa Snapshot yang saya sendiri masih belum paham kenapa bisa gagal terhapus.

Jika kita tidak menghapus Snapshot yang gagal terhapus tersebut lama-kelamaan akan membuat ruang penyimpanan (HDD/SSD) semakin terkikis habis karena semakin banyak selisih data yang tersimpan antara Snapshot yang gagal terhapus dengan kondisi terkini.

Mendeteksi Snapshot yang gagal terhapus

Untuk mencaritahu apakah ada Snapshot yang gagal terhapus kita bisa membandingkan Snapshot yang terdata oleh Snapper dengan jumlah Snapshot yang ada di tempat Snapshot itu berada.

Melihat data Snapshot dengan Snapper

Untuk melihat daftar Snapshot yang terdata oleh Snapper, kita bisa menjalankan perintah su -c "snapper list". Atau jika Anda mempunyai lebih dari satu konfigurasi Snapper (seperti saya), tambahkan opsi -a untuk menampilkan daftar Snapshot dari semua konfigurasi, su -c "snapper list -a".

Melihat jumlah Snapshot

Untuk melihat jumlah sebenarnya dari Snapshot kita bisa menggunakan perintah standar Linux, yaitu su -c "ls /.snapshots". Untuk Snapshot yang berada di konfigurasi home (jika Anda punya), jalankan su -c "ls /home/.snapshots" dan seterusnya (bisa dilihat dengan perintah su -c "snapper list-configs").

Perintah ls harus dijalankan dengan akses root karena direktori tersebut hanya bisa dilihat oleh root.

Bandingkan

Bandingkan jumlah Snapshot yang muncul dari perintah snapper dan ls. Jika sama berarti aman. Jika jumlah dari perintah ls lebih banyak, berarti ada Snapshot yang tidak terdata oleh Snapper.

Perhatikan/cari nomor Snapshot yang ada di perintah ls tapi tidak ada di perintah snapper. Snapshot inilah yang seharusnya sudah terhapus.

Menghapus Snapshot

Ada tiga cara untuk menghapus Snapshot yang tidak kita inginkan ini, yaitu:

  1. Cara barbar, dengan perintah rm -rf.
  2. Cara yang cukup bisa diterima, dengan perintah btrfs subvolume delete.
  3. Cara elegan, yaitu dengan mengembalikan Snapshot tersebut ke Snapper untuk kemudian dihapus secara alami.

Backup data dan siapkan rescue system

Sebelum menjalankan proses penghapusan sebaiknya backup semua data penting ke partisi lain atau ke penyimpanan eksternal untuk mengantisipasi kerusakan sistem, terutama jika Anda memilih cara pertama dalam menghapus Snapshot.

Siapkan juga installer di thumb drive/flashdisk atau DVD untuk persiapan install ulang jika Anda menggunakan cara pertama, atau persiapan fsck (btrfs check) filesystem jika Anda menggunakan cara kedua. Cara kedua bisa dikategorikan aman, hanya saja menghapus Snapshot dengan cara ini kadang membuat metadata menjadi tidak klop yang membuat Btrfs menjadi read-only sebagai proteksi menghindari kehilangan data. Memperbaiki filesystem yang read-only juga bisa dilakukan dengan live system sebagai alternatif jika Anda sudah tidak memiliki ISO installer.

Cara pertama, rm -rf

  1. Cari tahu subvolid dari Snapshot yang akan dihapus dengan perintah su -c "btrfs subvol list /" | grep <nomor_snapshot>. Ganti <nomor_snapshot> dengan nomor Snapshot yang akan dihapus. Perintah ini akan menampilkan keluaran: ID <subvolid> gen <dan_seterusnya>.
  2. Kaitkan/mount subvolume di mana Snapshot yang akan dihapus berada ke sebuah direktori (biasanya /mnt) dengan perintah su -c "mount -o subvolid=<subvolid_dari_perintah_1> /dev/sdXY /mnt", di mana sdXY adalah partisi tempat Snapshot berada, misal /dev/sda2.
  3. Cari tahu lokasi Snapshot yang akan dihapus yang berada di /mnt dengan perintah su -c "btrfs subvol list /mnt" | grep <nomor_snapshot>. Ganti <nomor_snapshot> dengan nomor Snapshot yang akan dihapus.
  4. Hapus Snapshot tersebut dengan perintah su -c "rm -rfv /mnt/<nomor_snapshot>". Ganti <nomor_snapshot> dengan nomor Snapshot yang akan dihapus.
  5. Lepaskan kaitan/unmount subvolume dengan perintah su -c "umount /mnt".

Coba jalankan ulang komputer. Jika berjalan normal (tidak kernel panik atau kehilangan root filesystem) atau tidak menjadi read-only berarti aman dan Anda tidak salah hapus subvolume. Lanjutkan aktivitas Anda.

Cara kedua, btrfs subvol delete

Jalankan langkah 1 hingga 3 dari cara pertama. Lalu:

  • Hapus Snapshot tersebut dengan perintah su -c "btrfs subvol delete /mnt/<nomor_snapshot>/snapshot". Ganti <nomor_snapshot> dengan nomor Snapshot yang akan dihapus.
    Lanjutkan ke langkah 4 dan 5 dari cara pertama.

Coba jalankan ulang komputer. Jika berjalan normal (tidak menjadi read-only) berarti aman. Lanjutkan aktivitas Anda.

Cara ketiga, kembalikan Snapshot ke Snapper

Tidak terdatanya Snapshot oleh Snapper biasanya karena subvolume /.snapshots/<nomor_snaphot>/snapshot masih ada (tidak terhapus), tapi file /.snapshots/<nomor_snapshot>/info.xml hilang atau kosong (tidak ada isinya).

Untuk mengembalikan Snapshot ke Snapper kita harus mengembalikan file info.xml ke kondisi seharusnya. Caranya dengan menyalin file info.xml dari Snapshot yang lebih baru ke Snapshot yang tidak terdata Snapper lalu mengubah isinya supaya sesuai dengan Snapshot tersebut.

Kita umpamakan Snapshot yang tidak terdata adalah nomor 567 dan Snapshot yang lebih baru adalah nomor 1234 (anggap saja Snapshot nomor 568 sampai nomor 1233 sudah terhapus).

  1. Salin file info.xml dari Snapshot 1234 ke Snapshot 567 dengan perintah su -c "cp /.snapshots/1234/info.xml /.snapshots/567/".
  2. Ubah nomor Snapshot di info.xml yang baru saja disalin supaya sesuai dengan Snapshot 567 dengan perintah su -c "sed -i 's/1234/567/' /.snapshots/567/info.xml". Ubah juga tanggalnya jika perlu, tapi ini hanya opsional saja. Jika Anda tidak mengerti dengan yang saya maksud, baca file tersebut dengan perintah su -c "cat /.snapshots/567/info.xml", terdapat informasi tanggal di sana.
  3. Biarkan sistem menghapus Snapshot tersebut secara alami pada waktunya. Jika Anda tidak sabar ingin segera menghapusnya, jalankan service snapper-cleanup dengan perintah su -c "systemctl start snapper-cleanup.service". Atau bisa langsung menggunakan perintah snapper, yaitu su -c "snapper -c root delete 567", bisa juga ditambah opsi --sync supaya ruang penyimpanan segera dikembalikan, su -c "snapper -c root delete --sync 567".

Hapus Snapshot yang berada di konfigurasi lain

Jika Anda punya lebih dari satu konfigurasi Snapper (seperti saya) dan juga ada Snapshot yang gagal terhapus, ulangi cara di atas untuk konfigurasi lain. Yang membedakan hanya lokasi di mana direktori .snapshots berada. Anda bisa memeriksanya dengan perintah su -c "snapper list-configs", di sana ditunjukkan di mana lokasi subvolume berada, tinggal ditambahkan .snapshots di belakangnya. Misal untuk subvolume /home lokasi .snapshots berada di /home/.snapshots, dan seterusnya.


Tulisan ini bisa dibaca juga di https://kikisyahadat.github.io/2020/07/29/membersihkan-snapshot-yang-tertinggal.html

Lanzada la cuarta actualización de Plasma 5.19

Tal y como estaba previsto en el calendario de lanzamiento de los desarrolladores, hoy martes 28 de julio la Comunidad KDE ha comunicado que ha sido lanzada la cuarta actualización de Plasma 5.19. Una noticia que aunque es esperada y previsible 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 cuarta actualización de Plasma 5.19

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.

Lanzada la cuarta actualización de Plasma 5.19

De esta forma, el martes 28 de julio ha sido lanzada la cuarta actualización de Plasma 5.19, 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.19

Como he dicho en la introducción esta versión de Plasma no ofrece muchas novedades y los desarrolladores se han dedicado más a pulir la versión anterior e ir mejorando la experiencia de uso.

No obstante, tal y como se comentó en la entrada que se realizó en el día de su lanzamiento, tenemos algunas novedades como las siguientes:

  • Mejoras en los plasmoides: reescrito al pack de widgets de System Monitor o los de la bandeja del sistema, por poner un par de ejemplos.
  • Completada la colección por defecto de avatares de usuarios.
  • Mejoras en la consistencia entre módulos de las Preferencias del Sistema.
  • Optimización de la herramienta de indexación de ficheros.
  • Rediseñado KinfoCenter.
  • Mejoras en Kwin, Wayland y Discover.

Más información: KDE