task spooler is a Unix batch system where the tasks spooled run one after the other. The amount of jobs to run at once can be set at any time. Each user in each system has his own job queue. The tasks are run in the correct context (that of enqueue) from any shell/process, and its output/results can be easily watched. It is very useful when you know that your commands depend on a lot of RAM, a lot of disk use, give a lot of output, or for whatever reason it's better not to run them all at the same time, while you want to keep your resources busy for maximum benfit. Its interface allows using it easily in scripts. 

For your first contact, you can read an article at linux.com, which I like as overview, guide and examples (original url). On more advanced usage, don't neglect the TRICKS file in the package.

Synonym is a small utility tool to find synonyms directly from the command line.
It is using the thesaurus.altervista.org API to query for words.

List of supported languages:

en, fr, cs, el, es, da, de, hu, it, no, pl, pt, ro, ru, sk

It’s been known for years now that SSH servers can (and should) be hardened by removing weak default algorithms. For example, recent versions of OpenSSH ship with algorithms suspected of being back-doored by the NSA (i.e.: ECDSA with the NIST P-curves), along with other algorithms with sub-128bit security levels.

But did you know that client software can be hardened too?
Why Harden Client Software?

In a world where all servers are properly hardened, there would be no need to re-configure client software. However, server hardening is unfortunately more rare than it should be, and you can only do it for machines you directly control. In that case, it’s very useful to upgrade your client’s defaults so you have assurance that only strong connections will be made.

What explains the popularity of terminals with 80×24 and 80×25 displays? A recent blog post "80x25" motivated me to investigate this. The source of 80-column lines is clearly punch cards, as commonly claimed. But why 24 or 25 lines? There are many theories, but I found a simple answer: IBM, in particular its dominance of the terminal market. In 1971, IBM introduced a terminal with an 80×24 display (the 3270) and it soon became the best-selling terminal, forcing competing terminals to match its 80×24 size. The display for the IBM PC added one more line to its screen, making the 80×25 size standard in the PC world. The impact of these systems remains decades later: 80-character lines are still a standard, along with both 80×24 and 80×25 terminal windows.

In this blog post, I'll discuss this history in detail, including some other systems that played key roles. The CRT terminal market essentially started with the IBM 2260 Display Station in 1965, built from curious technologies such as sonic delay lines. This led to the popular IBM 3270 display and then widespread, inexpensive terminals such as the DEC VT100. In 1981, IBM released a microcomputer called the DataMaster. While the DataMaster is mostly forgotten, it strongly influenced the IBM PC, including the display. This post also studies reports on the terminal market from the 1970s and 1980s; these make it clear that market forces, not technological forces, led to the popularity of various display sizes.

Collection of random scripts that make my life in the Linux console way simpler.

Do not expect readability, stability, compatibility, portability, applicability, or survivability.

Most of them are just a verbatim dump of what I'm using on my system(s). Simply sharing them to give back to the community. Written in shell, bash, python, and even php.

Unified access to the best community driven cheat sheets repositories of the world.

Let's imagine for a moment that there is such a thing as an ideal cheat sheet. What should it look like? What features should it have?

Concise — It should only contain the things you need, and nothing else.
Fast — It should be possible to use it instantly.
Comprehensive — It should contain answers for every possible question.
Universal — It should be available everywhere, anytime, without any preparations.
Unobtrusive — It should not distract you from your main task.
Tutoring — It should help you to learn the subject.
Inconspicuous — It should be possible to use it completely unnoticed.

Such a thing exists! It's easy to install and there's even auto-complete.

finds bugs in your shell scripts.
You can cabal, apt, dnf, pkg or brew install it locally right now.
Paste a script to try it out:

Consistent security controls and high reliability are common expectations for any systems administrator. How do you deliver both on a network with thousands of servers supporting thousands of engineers? Most off-the-shelf solutions require a compromise in at least one of these areas — and we refused to accept this.

Most systems administrators use the industry-standard Secure Shell (SSH) for accessing systems, and yet many of its special features are not widely leveraged. At Facebook, we take advantage of those features to use SSH in a way that is reliable, secure, and manageable. SSH, more specifically OpenSSH, has a great way to provide both the security and reliability we require: signed certificates with principals.

Automatically show a cheat sheet or notes for any command focused in tmux. e.i. Show vim, zsh, tmux notes/key-combos in a pane when using them.

OProfile has been around for decades, and for some time was the workhorse of performance profiling on Linux®-based systems, and can serve the same role today. However, OProfile is not included in Red Hat Enterprise Linux (RHEL) 8 beta, and so it may be prudent for OProfile users to start considering alternative tools. Analogous projects which compare very favorably to OProfile in features, ease-of-use, and vitality of the community do exist. One such project is the Linux perf command. Until recently, when compared to OProfile, perf had some drawbacks such as lack of support for Java™ just-in-time (JIT) compiled programs and hardware event mnemonics, but these have been addressed in recent releases. This tutorial offers current OProfile users a roadmap for transitioning from OProfile to perf.

If you do a significant amount of programming, you'll probably end up with build artifacts scattered about. sn is a tool to help you find those artifacts.

sn is also a replacement for du. It has nicer output, saner commands and defaults, and it even runs faster on big directories thanks to multithreading.

I'm taking a look at twelve "obscure" window managers.

systemd is, to put it mildly, controversial. Depending on who you ask it's either a complete violation of the UNIX philosophy, a bloated pile of bugs, a complete violation of the elegant simplicity it replaced or, it most cases, some or all of the above.

So why have so many Linux distributions taken to it? Is it as bad as people say? Are the BSD projects right to be avoiding it?

Let's look into the history of UNIX userland bootstrapping and the factors that lead to the creation of systemd, why it's turned out the way it has, and what there is to be learned from it.

Clickbaity title ahoy!

In the linux world they can all look the same from the point of view of the user at the keyboard. The differences are in how they interact with each other.

The shell is the program which actually processes commands and returns output. Most shells also manage foreground and background processes, command history and command line editing. These features (and many more) are standard in bash, the most common shell in modern linux systems.

A terminal refers to a wrapper program which runs a shell. Decades ago, this was a physical device consisting of little more than a monitor and keyboard. As unix/linux systems added better multiprocessing and windowing systems, this terminal concept was abstracted into software. Now you have programs such as Gnome Terminal which launches a window in a Gnome windowing environment which will run a shell into which you can enter commands.

The console is a special sort of terminal. Historically, the console was a single keyboard and monitor plugged into a dedicated serial console port on a computer used for direct communication at a low level with the operating system. Modern linux systems provide virtual consoles. These are accessed through key combinations (e.g. Alt+F1 or Ctrl+Alt+F1; the function key numbers different consoles) which are handled at low levels of the linux operating system -- this means that there is no special service which needs to be installed and configured to run. Interacting with the console is also done using a shell program.

Ever wondered whether htop could be used to render the graphics of cult video games? I know I have. In order to quench our curiosity and for your viewing pleasure, I created doom-htop

The new "Simple standalone #SSH Agent for #OpenPGP cards" (https://crates.io/crates/openpgp-card-ssh-agent) is now available as a package for #Arch Linux, by the way :arch: 😏

This agent offers a frictionless UX when using ssh with keys that are stored on OpenPGP card devices: No more ongoing PIN entry required! 🚀

@dvzrv has once again done amazing packaging and documentation work! 🥳 Thank you 😃

See https://wiki.archlinux.org/title/SSH_keys#OpenPGP_card_ssh-agent for details.

Das Problem lag in den Weiterleitungsregeln des HTTP-Servers. Hier war "/Verse" als Startseite mit einem großgeschriebenen Anfangsbuchstaben definiert, was dazu führte, dass die HTTP-Weiterleitung nicht ordnungsgemäß funktionierte. Nachdem dies korrigiert wurde und "/verse" als Startseite festgelegt wurde, funktionierte die HTTP-Weiterleitung einwandfrei, und somit war das ACME-Protokoll auf den jeweiligen Domino-Servern einsatzbereit.

Right now, I want to talk about the heritage of these input/output mechanisms. Why is it that punched paper tape and the teleprinter were the most obvious way to interact with the first electronic computers? As you might suspect, the arrangement was one of convenience. Paper tape punches and readers were already being manufactured, as were teleprinters. They were both used for communications.

Fasd (pronounced similar to "fast") is a command-line productivity booster. Fasd offers quick access to files and directories for POSIX shells. It is inspired by tools like autojump, z and v. Fasd keeps track of files and directories you have accessed, so that you can quickly reference them in the command line.

The name fasd comes from the default suggested aliases f(files), a(files/directories), s(show/search/select), d(directories).

Fasd ranks files and directories by "frecency," that is, by both "frequency" and "recency." The term "frecency" was first coined by Mozilla and used in Firefox (link).

GNU Stow is a symlink farm manager which takes distinct packages of software and/or data located in separate directories on the filesystem, and makes them appear to be installed in the same place. For example, /usr/local/bin could contain symlinks to files within /usr/local/stow/emacs/bin, /usr/local/stow/perl/bin etc., and likewise recursively for any other subdirectories such as .../share, .../man, and so on.

This is particularly useful for keeping track of system-wide and per-user installations of software built from source, but can also facilitate a more controlled approach to management of configuration files in the user's home directory, especially when coupled with version control systems.

Stow is implemented as a combination of a Perl script providing a CLI interface, and a backend Perl module which does most of the work. Stow is Free Software, licensed under the GNU General Public License.