Home Home > Tag > 15
Sign up | Login

Posts Tagged ‘15’

KDE and openSUSE: Plasma 5.14, Qt 5.12 and more

October 17th, 2018 by

Plasma 5.14

Plasma 5.14 was released with many improvements.

It was planned to have it in a released in a Tumbleweed snapshot on the same day, but openQA issues prevented snapshot 20181008 from getting published. Instead, Tumbleweed users got it with snapshot 20181009 on Thursday morning. Currently, 5.14.1 is staged to be accepted in Tumbleweed.

To get it on Leap 15 (and even 42.3 with restrictions), you can add https://en.opensuse.org/SDB:KDE_repositories#KDE_Frameworks_5.2C_Plasma_5_and_Applications. Note that those are not part of the official distribution and therefore not as well supported.

KDE:Unstable drops support for Leap 42.3

The KDE:Unstable projects will drop support for openSUSE 42.3 next week.

Builds of KDE software from git master have been available for Leap 15 even before the official release, which should’ve given everyone enough time to migrate.

The Argon media got switched to Leap 15 just after release as well. If you haven’t heard of Argon (and Krypton) yet, they’re installable live media with the latest version of KDE software on Leap and Tumbleweed.

See the wiki article (https://en.opensuse.org/SDB:Argon_and_Krypton) for more information.

Migrating to Leap 15 also means that less system libraries (like libinput) need to be replaced, as the version in Leap 15 is sufficient for now.

If you haven’t migrated to Leap 15 yet, read https://en.opensuse.org/SDB:System_upgrade#Command_line_2. The provided instructions work just fine for the KDE:Unstable repositories.

Goodbye to Webkit (from a default install)

Did you know that two major browsers, Safari and Chromium, are based on KDE software? That’s right, KHTML was used by Apple as foundation when creating the WebKit Browser engine. During the development of Chrome, Google forked WebKit into Blink. (more…)

syslog-ng vs. systemd’s journald

April 30th, 2018 by

This blog is part of a series of technical blogs leading up to the release of openSUSE Leap 15. All of the blogs provide a use case regarding openSUSE Leap and the packages available in the distribution. Happy reading.


Authored by Peter Czanik

People often ask me what to use: systemd’s journald or syslog-ng? The quick answer is that most likely both, but it depends on how you use your computer(s). If you have a single standalone machine, journald is probably enough. There is even a nice desktop application to view the logs in the journal. But once you have multiple machines to manage, using syslog-ng has many advantages.

Even if you use syslog-ng, local system logs are collected by journald. It is an integral part of systemd and cannot be uninstalled. Luckily, syslog-ng can read log messages from the journal. If journald stores additional name-value pairs about an event, syslog-ng can read those as well.

So, why install syslog-ng? The short answer is: central logging.

Why is the central collection of logs such a big deal? One reason is ease of use, as central logging creates a single place to check logs instead of tens or thousands of devices. Another reason is availability – you can check a device’s log messages even if the device itself is unavailable for any reason. A third reason is security; when your device is hacked, checking the logs can uncover traces of the hack.

journald also has some central logging capabilities, but syslog-ng provides a lot more features and better performance:

  • journald was originally designed for local logs on desktops – where there are not that many logs. On the other hand, syslog-ng was designed for high-performance central log collection from the ground up.
  • syslog-ng can collect logs from many more sources, including pipes, sockets, and files. File sources are especially important, as many applications – like web servers – log to files and do that at a rate that journald cannot handle.
  • syslog-ng does more than simple log storage. It can process log messages in many ways: parse them to create name-value pairs for easier alerting and reporting, enrich them with geographical information (GeoIP), rewrite them for anonymization (see PCI-DSS or GDPR), or reformat them according to the requirements of the destination.
  • Filtering in syslog-ng makes very precise log routing possible, ensuring that all logs reach the right destination.
  • Speaking of destinations: there are many possibilities for storing log messages, not just flat files or other syslog servers as it was the case many years ago. For example, you can store logs in SQL databases, send logs to Splunk for further analysis using HTTP, store name-value pairs parsed from logs in MongoDB, or send an email alert using the SMTP destination.