Well, today I learned that if you add the Ethernet header – 36 bytes – then an MTU of 1500 plus that header is 1536 bytes, which is 12288 bits, which takes 2^12 microseconds to transmit at 3Mb/second, and because the Xerox Alto computer for which Ethernet was invented had an internal data path that ran at 3Mhz, then you could just write the bits into the Alto’s memory at the precise speed at which they arrived, saving the very-expensive-then cost of extra silicon for an interface or any buffering hardware.

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.

Terminal Phase is a side-scrolling shoot-em-up in the Gradius and R-Type tradition, but in text mode. In the terminal! It's free software created by Christopher Lemmer Webber [Patreon].

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.

K9s provides a terminal UI to interact with your Kubernetes clusters. The aim of this project is to make it easier to navigate, observe and manage your applications in the wild. K9s continually watches Kubernetes for changes and offers subsequent commands to interact with your observed resources.

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.

Control character origins (^G = BEL)

If you want your list to be included on awesome, try to only include actual awesome stuff in your list. After all, it's a curation, not a collection.

But what is awesome?
Only awesome is awesome
Research if the stuff you're including is actually awesome. Only put stuff on the list that you or another contributor can personally recommend. You should rather leave stuff out than include too much.

Multiplayer Tron in your terminal. Just run the command below and you'll be playing in seconds

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.

lab interacts with repositories on GitLab, including creating/editing merge requests, issues, milestones, snippets and CI pipelines.

The development team has focused on keeping lab a simple and intuitive command line interface for commands provided in the GitLab API. lab's aim is to provide GitLab users an experience similar to the GitLab WebUI with respect to errors and messages.

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!