Category: Pillars
Seasoned Linux professionals thoroughly know data formats: it is mandatory since these formats are used by many tools as:
It is straightforward that is mandatory to be familiar to Regular Expressions: many legacy tools like grep (in all of its flavours, such as egrep) and sed use them as pattern matching criteria. They should also know how to leverage on awk when a little bit of business logic is needed while processing data, and of course know most of the so called “coreutils” (sort, cut, wc, uniq, …). Modern Linux professionals are also skilled on format specific tools such as xpath and xmlstarlet (XML), jq (JSON) or yq (YAML).
In addition to that, Linux professionals should also have a thorough understanding of:
Honestly, in my experience, I saw too many technicians neglecting this topic, but believe me, this can be very dangerous.
The first Wayland release is dated 2012, and it was of course in a very early stage. Now 16 years have passed since the initial design, they say Wayland is mature enough that it is safe to remove X11 sessions. In the Wayland Tutorial - A Wayland HowTo post we will go through everything it is worth the effort to know about Wayland, trying to answer the question: do Wayland replace the whole X Window system, or do it replace just the X11 protocol?
Even just because of its very long service lifetime, it is certainly worth the effort to have a look at this amazing piece of software. It does not matter if we are about to switch to Wayland (that by the way cannot completely replace the whole X Window System - think for example to XDMCP): the truth is that systems running X Windows will stay here for 10 years more, so 'm sure it is still worth the effort to have a good understanding of it. The "X Window Tutorial - X Display Server HowTo And Cheatsheet" post provides you with all the necessary skills to become an expert on this amazing piece of software that really made the story of UNIX and Linux.
X Window System is a legacy (1984) windowing system, that is a system providing the basic framework for a GUI environment initially developed as part of Project Athena at MIT. The currently available X protocol version is 11 (dated 1987!) - hence often people refer to X Window as "X11''.
It is really time I wanted to write a few posts on this amazing software that really made the story of IT on the UNIX and Linux platforms: it is one of my favorite software ever, it was really impressive in those years being able to run an application on a host while being able to just render on a remote display.
In the X window - remote display manager (XDMCP) and thin clients we see how to reproduce on a modern Linux distribution a very common setup of the late '80 and early '90: a remote server running applications rendered on X Window based thin clients.
In the "OpenSSL CA tutorial - a full-featured OpenSSL PKI" post we set-up a full featured Public Key Infrastructure with Root and Intermediate Certificate Authorities, Indirect CRL and OCSP Responders. To have a go with that PKI, we also generated an Extended Validation (EV) certificate ("/tmp/foo.crt").
In this post we are using the same PKI we set up in that post, the EV certificate we generated and we also generate a new Organization Validated (OV) certificate: the goal this time is showing how to deal with Indirect CRL generation, CRL validation and OCSP validation.
OpenSSL is a full featured tool capable not only to generate keys and certificates, but also to provide every facility a PKI must have, such as indirect CRL and OCSP responders: these features, along with certificate's best practices such as the Certification Practice Statement (CPS), publishing CRL Distribution Points URL, OCSP Responders URL, CA Issuers URL, are the topics of the OpenSSL CA tutorial - A full-featured openssl PKI.
As we saw in our post on Symmetric And Asymmetric Cryptography, asymmetric key pairs can be used to encrypt and digitally sign documents, but have a huge shortcoming: since they are just keys, they don't provide the metadata necessary to enable people to securely identify their owner. As we saw in the post on GNU Pretty-Good Privacy, GPG addresses this shortcoming by wrapping the key into a container object (the GPG key) that also embeds some metadata about the owner of the key. Of course also the IETF addressed this problem, defining the standard for X.509 certificates (currently X.509v3). X509 Certificates Howto & Public Key Infrastructure Tutorial explores X.509 certificates and how they are trusted by the means of a Public Key Infrastructure.