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!

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.

It is time for me to re-do my old thread about the origins of "80 columns" and how it can very well be related to pretty ancient stuff, not dissimilar to "space shuttle and horse's rear end".

As you know, the default mode on IBM PCs is text 80x25. The limitation of 80 columns per line, also known as "80 column rule" is still widespread; for example, that's the rule for Linux kernel. But why 80? Why not 70 or 90?

The answer to that is usually "IBM punch cards are 80 characters wide", but things are more interesting than that!

First, the commonly accepted column width was supposed to be 72. American typewriters used to have just 72 columns, earlier DEC terminals supported only 72 columns, and even IBM punch cards had only 72 columns for text.

Second, yes, IBM punch cards were 80 characters wide, but why?

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.

zoxide is a smarter cd command, inspired by z and autojump.

It remembers which directories you use most frequently, so you can "jump" to them in just a few keystrokes.
zoxide works on all major shells.

Sticker. Hm. "Sticker"

$ Ohne Graphik, trotzdem da
$ Commandline only Antifa

I embraced OS X as soon as it was available and have never looked back. So a lot of In the Beginning...was the Command Line is now obsolete. I keep meaning to update it, but if I'm honest with myself, I have to say this is unlikely.[1]

In July 2004 I found myself sitting alone in the dark, on the enclosed deck of a ferry boat oozing between fog-shrouded islands of the Alaskan coast. The scenery was haunting, but after the first three hours, I decided to occupy myself by finally reading Neal Stephenson's essay about the command-line. Halfway through it I began crossing things out, and scribbling comments in the margin. The essay was five years old, and in dire need of a fresh perspective.

Months later, I learned that Stephenson himself was dissatisfied with the essay. He wrote that it, "is now badly obsolete and probably needs a thorough revision." An "Ask Slashdot" poll quoted him as saying, "I keep meaning to update it, but if I'm honest with myself, I have to say this is unlikely."

Though I have fleshed out my original comments into longer, more structured pieces, it is not my intention to replace or revise Neal Stephenson's original writing. His original essay is a much more cohesive and entertaining read than my notes are. (He is a Writer, after all. I consider myself a code-monkey by comparison.) In fact, my notes do not hold together unless they use the original essay as a framework, and that's why his entire essay is reproduced here, with my comments color-coded. And yes, I have sought and obtained permission from Neal to do this.

Difftastic is a structural diff tool that compares files based on their syntax.

Like many things in git, zdiff3 is one of those hidden features that I wish was set as the default option. It has made my day to day development much easier when it comes to resolving conflicts and it's a nice little improvement over diff3. If you want to enable zdiff3 by default on versions of git >= 2.35, you can run git config --global merge.conflictStyle zdiff3. If you just want to give it a test run next time without setting that option to see if you like it you can also run git checkout --conflict zdiff3 ./conflicted/file/path to checkout just the one conflicted file again with the zdiff3 algorithm.