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!

Saya mengubah sedikit kode pada https://github.com/zezevavai/ubuntu-server-initial-setup

dengan menambahkan baris ini :

DIST_CODE=cat /etc/lsb-release | grep -i code | cut -d "=" -f2
sudo sed -i "s/bionic/${DIST_CODE}/g" /etc/apt/sources.list

Perintah diatas akan mengganti tulisan versi di repository (misalnya bionic untuk versi Ubuntu 18.04) menjadi repo yang sesuai dengan versi yang digunakan (misalnya menjadi xenial pada Ubuntu 16.04 atau menjadi focal pada Ubuntu 20.04)

Harapannya, script ini tidak terbatas pada Ubuntu versi 18.04, melainkan dapat juga digunakan pada versi lainnya.

Saya juga menambahkan pengecekan, jika SSH Key dikosongkan/skip, pilihan “Password Authentication di SSH” akan tetap diset “Yes” agar akses remote via SSH tidak terkunci.

Terakhir, tadi pagi saya membuat simulasi penggunaan dalam bentuk video dan menguploadnya ke Youtube.

Catatan : Saya belum sempat mencoba scriptnya pada versi Ubuntu yang lain. Kalau ada yang mau coba, sebaiknya lakukan backup konfigurasi terlebih dahulu.

SUSE a envoyé une proposition à la communauté openSUSE pour rapprocher les flux de code de SUSE Linux Enterprise et de openSUSE Leap. La proposition comprend des binaires SLE pour la version communautaire.

Rapprocher les flux de code pour fournir une compatibilité totale offre plusieurs avantages à la communauté pour l'avenir, tels que l'utilisation de code de meilleure qualité en raison du nettoyage des fichiers de spécifications, une relation améliorée entre les deux distributions, un rapport de bogue plus facile, moins de flux de code à maintenir, des paquets largement testés et l'inclusion d'architectures prises en charge par SLE comme s390x.

"Grâce à ce changement, nous pouvons mieux utiliser nos ressources car une seule base de code converge, donc une cible de construction de moins à considérer", a déclaré Axel Braun, membre du conseil d'administration d'OpenSUSE, dans un e-mail envoyé à la communauté à propos de la proposition. "Tous ceux qui font des paquets pour Leap et pour Package Hub en bénéficieront immédiatement."

La proposition a fourni une approche par étapes pour la mise en œuvre de la vision. L'e-mail répertorie les options suivantes:

• Fusionner autant que possible les bases de code pour l'intersection d'OpenSUSE Leap 15.2 et de SUSE Linux Enterprise 15 SP2 sans perte de stabilité ou de fonctionnalité. (SUSE a en fait commencé à fusionner Leap avec SUSE Linux Enterprise.)
• Créer une version intermédiaire d'OpenSUSE Leap dans laquelle des binaires SLE sont utilisés à l'intérieur (période d'octobre 2020) en parallèle avec Leap 15.2 classique.
• Construire openSUSE Leap 15.3 avec les binaires SLE inclus par défaut (en supposant l'accord de la communauté).

La distribution Leap partage déjà une quantité importante de code source principal avec SLE. Leap 15.2 sera basé sur les sources de SLE 15 SP 2, mais pas sur les binaires.

La communauté discutera probablement de la proposition sur la façon d'intégrer les binaires SLE dans une nouvelle configuration de construction pour Leap et aidera à identifier tout problème susceptible de modifier les processus ou les flux de travail. La construction du projet intermédiaire dans OBS devrait avoir lieu en mai. La construction devrait donner aux contributeurs et développeurs openSUSE l'occasion de mieux comprendre la proposition de SUSE.

"Nous avons une idée de la configuration dans build.opensuse.org", a répondu Adrian Schröter de l'équipe OBS. "Je prévois d'avoir un premier prototype de la configuration de la construction dans les trois prochaines semaines. Nous devons garder à l'esprit que c'est vraiment une toute nouvelle façon de développer une distribution."

L'équipe de publication a évalué tous les paquets et les implications techniques pour l'intégration des packages SLE supplémentaires, afin de fournir une certaine clarté à la communauté sur la façon dont une implémentation technique pourrait fonctionner au mieux.

Il existe environ une douzaine de paquets qui sont techniquement difficiles à implémenter pour une compatibilité totale avec les distributions d'entreprise et de communauté.

"Il a fallu un certain effort pour créer un plan acceptable par toutes les équipes impliquées", a expliqué Lubos Kocman, responsable de la publication de...

Proses instalasi Ubuntu server 18.04 64 bit secara prinsip dapat dilakukan dengan mudah dan tidak memerlukan pengetahuan yang rumit. Saat ini sebagian besar penyedia layanan cloud sudah langsung melakukan by pass proses instalasi, sehingga saat melakukan order sebuah layanan cloud berbasis Ubuntu server, kita dapat langsung diberikan akses SSH atau remote server tanpa harus melakukan instalasi secara manual.

Meski demikian, adakalanya kita memerlukan proses instalasi secara manual, terutama jika ingin membuat sebuah master atau template sistem yang nantinya akan digunakan untuk berbagai keperluan. Proses instalasi manual tersebut bisa mengikuti tahapan sebagai berikut :

I. PERSIAPAN

Sebelum memulai proses instalasi, pastikan beberapa hal berikut ini agar semuanya berjalan dengan baik dan lancar.

1. Media Instalasi, apakah menggunakan USB atau DVD install atau menggunakan file ISO (jika instalasi diatas virtualisasi server seperti VMware atau VirtualBox)
2. File ISO Ubuntu server 18.04 64 bit yang bisa didownload dari sini : https://ubuntu.com/download/server. Untuk server di Indonesia, dapat menggunakan mirror server lokal seperti :
   – Server kambing.ui.ac.id
   – Server repo.ugm.ac.id
   – Server kebo.pens.ac.id
3. Prosesor minimal Dual Core 2 GHz
4. Disk minimal 25 GB (bisa kurang jika sekedar untuk test)
5. Akses Internet untuk update data saat proses instalasi

II MEDIA INSTALASI

Untuk proses instalasi pada server bare metal (fisik), gunakan installer USB flash disk. Meski bisa melakukan instalasi menggunakan CD/DVD, jauh lebih hemat jika menggunakan USB karena dapat dipergunakan kembali untuk keperluan yang lain.

USB installer bisa dibuat dengan menggunakan aplikasi Rufus atau Unetbootin.

Jika menggunakan mekanisme instalasi virtual, sebaiknya gunakan ISO installer karena lebih mudah dilakukan dan lebih cepat proses instalasinya.

III. PROSES INSTALASI

Setelah melakukan booting installer, proses selanjutnya adalah mengikuti panduan instalasi yang diberikan. Berikut adalah detail prosesnya :

Pilih Bahasa
Gunakan bahasa untuk instalasi sesuai keinginan, setelah itu tekan ‘ENTER.’

Layout Keyboard
Selanjutnya, pilih tata letak keyboard yang disukai dan tekan ‘ENTER.’

Ubuntu atau MAAS (Metal As A Service)
Tahap berikutnya adalah pilihan untuk instalasi Ubuntu. Pilih pilihan pertama untuk menginstal Ubuntu secara umum pada PC/Server. Pilihan lain berupa ‘Install MAAS’ biasanya digunakan untuk instalasi basis cloud pada server fisik.

Jika pilihan ini ada, pilih pilihan “Ubuntu” dan tekan ENTER.

Pengaturan Jaringan
Pada tahap ini, prosesnya adalah memilih adaptor jaringan dan menerima penetapan alamat IP otomatis jika sistem dikonfigurasi dalam lingkungan server DHCP. Pilihan lain adalah mengatur alamat IP secara manual. Silakan pilih konfigurasi yang diinginkan sesuai dengan mekanisme setting di lingkungan masing-masing.

Pengaturan Proxy
Tahap selanjutnya akan menanyakan alamat server proxy. Setting ini diperlukan jika koneksi internet membutuhkan akses melalui proxy server. Jika tidak menggunakannya, Tekan ENTER untuk langsung berpindah ke tahap selanjutnya

Mirror Repository
Tahap ini menentukan repository mana yang akan digunakan. Secara default Ubuntu akan memilih repository terdekat sesuai lokasi geografis, namun pilihan tersebut dapat diubah dengan memasukkan alamat repository lokal sesuai keinginan.

Berikut adalah beberapa contoh isian repository untuk mirror server di Indonesia :

• Server http://kambing.ui.ac.id/ubuntu/
• Server http://repo.ugm.ac.id/ubuntu
• Server http://buaya.klas.or.id/ubuntu
• Server http://kartolo.sby.datautama.net.id/ubuntu/
• Server http://mirror.poliwangi.ac.id/ubuntu/

Pengaturan Hard Disk
Tahap ini akan memberikan pilihan untuk melakukan konfigurasi hard disk sesuai keinginan. Ada pilihan untuk menggunakan seluruh disk jika tidak ada sistem operasi lain yang diinstal atau dapat memilih konfigurasi secara manual dan membuat beberapa perubahan, terutama jika ada dual/multi boot dengan sistem lain.

Setelah memilih konfigurasi yang diinginkan, lakukan verifikasi apakah semuanya sudah sesuai atau tidak. Jika ada kesalahan atau ada yang memerlukan penyesuaian lebih lanjut, tekan ‘BACK.’

Jika ingin memulai dari awal dengan pengaturan partisi disk, tekan ‘RESET.’

Jika semua sudah sesuai dengan konfigurasi yang diinginkan, tekan tombol “Continue” atau ‘Lanjutkan’ sebagai konfirmasi.

Akses Login
Berikan akses masuk/login pada server. Akses ini nantinya akan digunakan untuk melakukan konfigurasi lebih lanjut.

OpenSSH Server

Karena proses manajemen selanjutnya akan menggunakan akses remote, sebaiknya aktifkan akses OpenSSH Server saat instalasi.

Server snaps
Tahap ini memungkinkan pemilihan daftar services server yang akan digunakan, misalnya jika Ubuntu server yang diinstall akan digunakan untuk aplikasi Kubernetes, Docker, NextCloud dan lain-lain. Karena ini hanya digunakan sebagai basic atau master server, pilihan snaps server diskip dan tidak ada yang dipilih.

Setelah semua proses diatas, instalasi Ubuntu server akan dimulai. Lamanya proses install bervariasi, tergantung pada RAM, CPU, performa storage dan kecepatan internet server yang digunakan.

Reboot & Login ke Server
Setelah proses instalasi selesai, server bisa direboot untuk mulai digunakan untuk keperluan tertentu. Setelah proses boot selesai, lakukan proses login pada terminal server yang tersedia.

Selamat, setelah proses login berhasil berarti sudah berhasil melakukan instalasi Ubuntu server 18.04 64 bit dengan baik.

IV VIDEO TUTORIAL INSTALASI

Bagi rekan-rekan yang ingin melihat contoh instalasi Ubuntu Server 18.04 64 bit menggunakan VirtualBox, bisa melihat video Youtube dibawah ini :

V SETELAH INSTALASI

Setelah proses instalasi berhasil dilakukan, lakukan proses penyalinan data master atau proses cloning atau jadikan template agar bisa dipergunakan untuk keperluan yang berbeda-beda tanpa harus berulangkali melakukan proses instalasi yang sama.

Note: There is a print link embedded within this post, please visit this post to print it.

SUSE a propuesto a la comunidad de openSUSE que la versión Leap de esta y SUSE Linux Enterprise compartan binarios de código esencial

Hace unos días pudiste leer en el blog un artículo sobre la propuesta de colaboración más estrecha entre SUSE y la comunidad de openSUSE:

• https://victorhckinthefreeworld.com/2020/04/16/suse-y-opensuse-leap-colaborando-de-manera-mas-estrecha/

Hasta ahora openSUSE Leap y SUSE Linux Enterprise (SLE) compartían cierto código esencial, lo que hacía que openSUSE se beneficiara de un núcleo más estable y testeado.

Ahora SUSE ha propuesto que no sólo compartan código, si no que compartan binarios ya compilados ambos proyectos.

La propuesta se está debatiendo en las listas de correo de openSUSE, pero sin duda surgen muchas dudas al respecto.

En el artículo que he citado más arriba, en uno de los comentarios, un desarrollador de SUSE ofrece una respuesta que complementa muy bien al artículo dando más información al respecto.

Pero todavía hay muchas otras preguntas. Así que he decidido traducir una página de la Wiki de openSUSE en Inglés donde se plantean varias preguntas frecuentes y se ofrecen las respuestas.

La página traducida al español la puedes encontrar en este enlace:

• https://es.opensuse.org/FAQ/Colaboraci%C3%B3n_entre_SUSE_y_openSUSE_Leap

En ella se plantean diferentes preguntas que pueden surgir y se dan las respuestas que tratan de dar la información sobre los motivos de este acercamiento, los beneficios para ambos proyectos (Leap y SLE), y el plan a seguir para llevar a cabo el proyecto.

He tratado de hacerlo lo mejor posible, pero siempre se pueden corregir expresiones, mejorar traducciones, corregir errores o erratas, etc. Así que ¡no dudes en hacerlo!

Espero que esta traducción que he realizado sirva para despejar dudas y valga para aclarar algo más lo que SUSE ha propuesto a la comunidad de openSUSE.

Por mi parte me ha servido para “obligarme” a leer la página y al traducirla, servirme para entenderlo. Espero que también despeje tus dudas…

¿Será por lanzadores de aplicaciones en Plasma?. Como he dicho en varias entradas, buscar y ejecutar los programas en el entorno de trabajo Plasma de la Comunidad KDE es altamente personalizable. Hoy os presento Launchpad Plasma, otro lanzador de aplicaciones a pantalla completa con el que llegamos a los 140 plasmoides de KDE presentados en esta humilde bitácora.

Launchpad Plasma, lanzador de aplicaciones a pantalla completa – Plasmoides de KDE (140)

Seguimos con las posibilidades de personalización de Plasma 5 en cuanto a lanzadores de aplicaciones. Al lanzador tradicional, a su versión reducida, al lanzador de aplicaciones a pantalla completa y a Tiled Menu, el clon del menú de Windows, se les han unido poco a poco otros lanzadores como UMenu, Minimal Menu, Simple Menu, Ditto Menu o los Menu X y Menu Z.

A todos los anteriores se les une Lauchpad Plasma, otra creación de Adhe, un desarrollador que le ha cogido el gusto a hacer este tipo de contribuciones, y que nos ofrece un lanzador que ocupa toda la pantalla basado en DashBoard Menu  y que nos permite personalizar el tamaño de los iconos, la distancia entre ellos y las columnas visibles, entre otros aspectos.

Y como siempre digo, si os gusta el plasmoide podéis “pagarlo” de muchas formas en la nueva página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. 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 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 plasmoides?

Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.

En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.

Estoy seguro que el plasmoides de KDE número 139 presentado en este blog le encantará a un compañero que almeriense. Se trata de Markdown Plasmoid Original, un simple pero útil widget que nos puede facilitar mucho nuestro día a día.

Markdown Plasmoid Original – Plasmoides de KDE (139)

Seguimos con las posibilidades de personalización de Plasma 5, y en esta ocasión fijándonos en uno de estos que nos son útiles trabajando con documentos con nuestro ordenador.

Se trata de Markdown Plasmoid Original, un simple plasmoide creado por Joooscha que nos sirve como editor simple de este lenguaje de marcado ligero que se distribuye bajo licencia BSD.

Como he comentado, su funcionamiento es muy simple y soporta markdown normal, incluídas las tablas, y su aspecto puede ser personalizado mediante comandos css, como se puede ver en las opciones de configuración.

Y como siempre digo, si os gusta el plasmoide podéis “pagarlo” de muchas formas en la nueva página de KDE Store, que estoy seguro que el desarrollador lo agradecerá: puntúale positivamente, hazle un comentario en la página o realiza una donación. 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 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 plasmoides?

Para los no iniciados en el blog, quizás la palabra plasmoide le suene un poco rara pero no es mas que el nombre que reciben los widgets para el escritorio Plasma de KDE.

En otras palabras, los plasmoides no son más que pequeñas aplicaciones que puestas sobre el escritorio o sobre una de las barras de tareas del mismo aumentan las funcionalidades del mismo o simplemente lo decoran.

Daripada berulang-ulang melakukan hal yang sama saat melakukan setup server berbasis Ubuntu, lebih baik dibuat script untuk otomatisasinya. Saat ini masih berbasis Ubuntu 18.04 karena kebetulan paling sering pakai versi tersebut. Butuh sedikit tweak lagi agar bisa juga digunakan pada Ubuntu 16.04 atau Ubuntu 20.04 (yang akan rilis menjelang akhir April 2020)

https://github.com/zezevavai/ubuntu-server-initial-setup

Based on https://github.com/jasonheecs/ubuntu-server-setup with minor changes for Indonesian local repositoy

This is a setup script to automate the setup and provisioning of Ubuntu servers. It does the following:

• Change default repository to Indonesian Ubuntu Mirror
• Setup the timezone for the server (Default to “Asia/Jakarta”)
• Update and upgrade server for first time
• Adds a new user account with sudo access
• Adds a public ssh key for the new user account
• Disables password authentication to the server
• Deny root login to the server
• Setup Uncomplicated Firewall
• Create Swap file based on machine’s installed memory
• Install Network Time Protocol

Installation
SSH into your server and install git if it is not installed:

sudo apt-get update
sudo apt-get install git

Clone this repository into your home directory:

cd ~
git clone https://github.com/zezevavai/ubuntu-server-initial-setup.git

Run the setup script

cd ubuntu-server-initial-setup
./setup.sh

Script diatas bisa disesuaikan lagi agar bisa mendapatkan basis OS siap pakai sesuai kebutuhan masing-masing. Untuk todo list saya sendiri, saya upayakan bisa fleksibel saat menambahkan repository lokal Indonesia, jadi bisa dilengkapi dengan versi Ubuntu yang lain.

Untuk simulasi via video bisa merujuk ke link dibawah ini :