Well, cool. Hope it was helpful, then.

I’ll also mention one other point, if you’re a big emacs and Firefox user. Won’t solve the issue for URL bars or other non-webpage text, but if you do a fair bit of writing in HTML textareas in webpages, like on Lemmy instances or something, you can hand that off to emacs.

• Install the edit-server package for emacs (M-x list-packages, wait for the emacs package manager to load the list, go to edit-server, hit “i” to flag for install and “x” to execute, or M-x package-install and just type out “edit-server”).

• In an emacs instance run M-x edit-server-start (or set it up to always run automatically at emacs startup but I run multiple emacs instances).

• Grab the Edit with Emacs Firefox addon. Install.

Now, by default all textareas will have a little blue button at the bottom reading “edit”. Click it, and your textarea will open up in emacs. C-c C-c to commit changes back to the textarea (Or C-x C-c, if you’re exiting that instance of emacs). You can also right-click on the textarea and choose “Edit with Emacs”.

I have, in the past, recommended, if you use Unix systems in a technical way, knowing at least how to do the following in vi (and I use emacs):

• Close the program, discarding changes. From vim’s command mode, : q ! RET.

• Exit writing changes. From vim’s command mode, : w q RET.

• Move the cursor around. Today, usually you can get by with arrow keys – I haven’t been on a system where one thing or another was dicked up in a way that rendered arrow keys unusable in many years, but from Vim’s command mode, “h”, “j”, “k”, and ""l.

• Enter insert mode to Insert text. From vim’s command mode, “i”.

• Exit insert mode. From vim’s insert mode, ESC.

• Search for text. From vim’s command mode, “/”, the text to search for, and RET.

• Replace text. From vim’s command mode, “: %s/foo/bar/g” to change all instances of foo to bar in a given file.

If you’ve got that much and you ever find yourself on a system that only has vi available (and it may not be vim), you can at least do the basics.

But the widespread deployment of nano has made learning basic vi less important than was once the case. Even very small systems that I’ve run into tend to have nano.

Note that busybox, a popular statically-linked shell often used in a rescue-the-horribly-broken-system scenario, does not have nano but does have a minimal “vi”-alike, so you might still want to know vi in that case.

If you’re specifically wanting to fiddle the Firefox keybinding the way I have (which may be too much effort for some people to deal with re-learning), the setting is:

• Go change the GTK setting for the appropriate version of GTK. On my Debian trixie system, Firefox is using GTK 3:

    $ apt depends firefox|grep gtk
    
    WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
    
    Depends: libgtk-3-0t64 (>= 3.13.7)
    $
  

  I don’t know whether it will change to GTK 4 anytime soon.

• Go to about:config in the Firefox URL bar.

• Set ui.key.menuAccessKey to 0. Normally, IIRC — it’s been many years that I’ve had this set, so I don’t even really remember the original behavior for certain — Firefox uses Alt in sorta the same way Windows does, to open menus. I don’t like that, and this disables that functionality entirely to free up Alt.

• Set ui.key.accelKey to 18. This makes the now-free Alt act like Control does as regards Firefox keyboard shortcuts.

• I also have ui.key.contentAccess set to 0. It’s been many years since I’ve set this, but…let’s see. goes to look That disables the contentAccess key, prevents webpages from grabbing Shift-Alt-key sequences, which can also collide. Like, in the Lemmy HTML textarea that I’m currently writing this in, I can hit Shift-Alt-B and Shift-Alt-F to move the cursor forward and backward by a word while selecting text, the way I could in emacs (or, in emacs parlance, move point while extending the region).

The problem is that now you’ve got Firefox, where things like “Alt-A” will select all text, and if you use other GUI apps, other apps, which may be using “Control-A” for that, so you gotta train your muscles to deal with it. I haven’t thought about it in many years, as it’s automatic now, but I remember it being super-obnoxious when I started.

For me, it was worth it, because I use emacs all the time and Firefox all the time, and rarely use other graphical apps, so it reduced the amount of switching. But…depends on what someone’s particular situation is, whether that makes sense for them.

EDIT: Had accidently written ui.key.contentAccess twice. Corrected the first instance to be ui.key.menuAccessKey.

It was originally pico, which IIRC was bundled with the pine email client (a “tree name” pun off elm, an older email client, whose name came from “ELectronic Mail”; this pun extended to many other Unix email clients, like mulberry and such). I think that “pico” probably stood for something like “PIne COmposer”. Because it was designed to be particularly approachable, listed the basic commands at the bottom of the screen, and pine was installed on a lot of systems, it kind of got adopted as the “Unix notepad for the terminal” — a simple editor that most users could use for lightweight tasks. Then IIRC due to pine predating standard open-source licenses, the nano clone was created to be GPL.

searches

https://en.wikipedia.org/wiki/Pico_(text_editor)

Yeah, it’s “pine composer”, it was indeed bundled with pine. And apparently part of the problem was that the license didn’t fully spell out the conditions under which it could be redistributed.

I am even starting to miss my emacs keybinds when not using emacs (especially ctrl-k for killing from your cursor position to the end of the line ctrl-a for jumping to the beginning of a line and ctrl-e for jumping to the end of a line)

A number of software packages permit use of basic emacs keybindings.

It’s the default in bash, which uses readline. If someone is a vi user, they can enable vi keystrokes in software that uses readline with editing-mode vi in their ~/.inputrc.

For GTK-based apps, looking on my system:

GTK 1: in ~/.gtkrc:

gtk-key-theme-name = "Emacs"

GTK 2: in ~/.gtkrc-2.0:

gtk-key-theme-name = "Emacs"

GTK 3: in ~/.config/gtk-3.0/settings.ini

gtk-key-theme-name="Emacs"

GTK 4 apparently can’t do this.

Note that this can collide with other keybindings that a given GTK app has assigned to it. I moved the standard Firefox modifier key from Control to Alt to reduce the impact of that on my system. That was a little obnoxious to get worked into muscle memory, but I did ultimately manage it.

Yeah, the later images being posted are definitely soldering irons. I think that TurboWafflz is asking whether maybe the thing in the original Star Trek image that OP put up is intended to be a soldering iron, which is a fair question.

I’ve used probes with little hooks on the ends myself, but I imagine that there are pointy probes out there.

Depends pretty wildly on what you like.

Some things that I do:

I never want automatic locking — I always lock my machine manually when leaving it, with Super-\ (Super normally being the Windows key). I also want my monitor to power off after a few seconds in that mode, and then wake back up if I start typing. I also want to use a black screen rather than swaylock’s default white.

in my ~/.config/sway/config:

set $mod Mod4

# Handle session-locking triggered by stuff like loginctl lock-session
exec_always swayidle -w \
             lock 'myscreensaver.sh'

# Bind Super-backslash to trigger a session lock
bindsym $mod+backslash exec "loginctl lock-session""

in ~/bin/myscreensaver.sh:

#!/bin/bash
# Script that handles things necessary to "lock" the system when I'm away

# Pause any music that mpd is playing
mpc pause

swayidle \
    timeout 5 'swaymsg "output * dpms off"' \
    resume 'swaymsg "output * dpms on"' &
swaylock -c 000000
kill %1

By default, X11 (and Wayland, apparently, though I’ve spent less time looking at Wayland’s APIs) don’t “store” clipboard state – they just facilitate transferring copied data from one application to another application where it’s being pasted. This means that if one copies data in one application and then closes that application, the clipboard contents go away. I don’t really like this behavior. One way to avoid it is to use a “clipboard manager” — a piece of software that saves a copy of the data itself. If you install clipman and wl-clipboard, you can do this:

In ~/.config/sway/config:

# Make clipboard persist after application termination
exec_always flock -n $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY-wl-paste wl-paste --watch clipman store

I want to get notifications when my laptop battery is low. Install poweralertd, and then in ~/.config/sway/config:

# Power notification support
exec_always flock -n $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY-poweralertd poweralertd

I don’t use it that much, but Sway has a “scratchpad”, where one can stuff a window that one is working with. With this, I send the current window there with Super-Shift-minus then make it pop back up as a floating window with Super-minus:

# Scratchpad
bindsym $mod+shift+minus move window to scratchpad
bindsym $mod+minus scratchpad show

I have a mute button on my laptop’s keyboard. I make that mute the default PipeWire sound sink. In ~/.config/sway/config:

bindsym XF86AudioMute exec "wpctl set-mute @DEFAULT_AUDIO_SINK@ toggle"

I swap Caps Lock and left Control. This is how traditional Unix keyboards worked, and is generally more-friendly if you are using the Control key a lot more than Caps Lock. I’d consider this almost a precondition to use emacs without making your left pinky miserable. In ~/.config/sway/config:

input "type:keyboard" {
      xkb_options ctrl:swapcaps,compose:menu,compose:ralt
}

That also sets my menu key (on my desktop) and right Alt key (on my laptop, which doesn’t have a menu key) to be Compose. That way I can do things like type “ö” by hitting Compose o and then the double-quote key, or an em-dash (“—”) with Compose hyphen hyphen hyphen.

I don’t like keeping my mouse pointer visible unless I’m actually moving it. In my ~/.config/sway/config, this will hide it after three seconds:

# Hide mouse cursor after a period of inactivity.
seat seat0 hide_cursor 3000

I like to have a way to, using the keyboard, hide the latest notification shown by swaync, the default Sway notification manager. In ~/.config/sway/config:

bindsym $mod+grave exec "swaync-client --hide-latest"

Then Super-backtick will hide the most recent notification to show up.

One thing that I’ve found that I like is having my waybar not normally visible. When I need to glance at the bar, I can just hold the Sway modifier key to make it temporarily show up.

in ~/.config/sway/config:

bar {
    swaybar_command waybar
    mode hide
}

More screen space for whatever I’m actually doing. If something is so critical that it needs to grab my attention (e.g. battery low on a laptop) then I have it set up to send a message to the notification manager.

I imagine it’s rephrased “Copilot”.

the resulting error messages normally at least give you something to search for

lp0 on fire

And:

#include <errno.h>
#include <stdio.h>

int main (void) {
    errno=ENOANO;
    perror("");
    return 0;
}

Yields:

$ ./a.out 
No anode
$

Note that on current, systemd-based systems, one probably wants sudo journalctl -kb to show kernel messages for the current boot.

dmesg reads from the in-memory kernel ring buffer. That can be desirable in some cases, but as the name suggests, the “ring buffer” is a “ring” — it has a finite amount of space and eventually, the old stuff gets overwritten by the new stuff. The idea is that a userspace logging daemon, like journald (or syslogd on most older systems) has time to pull the data from the ring buffer out to (potentially much larger) log files on disk.

journalctl will also post-process the output to do things like convert the time-from-boot to a wall clock time, which is generally more useful for correlating with other things.

I think that the point being made here is that it’s not a great idea to hold an actually running soldering iron by the hot bit?

If so, I think that OP’s image is supposed to have some sort of thermal insulation stuff around the hot bit, that clear stuff.

If you don’t want it, you can hide it — most distros have some way to just show a splash screen that hides it. I always unhide it, as I can see hints of things going wrong.

The messages are from a wide variety of kernel subsystems (and, later in the boot process, daemons) and most people aren’t going to be familiar with everything. I could tell you what a lot of lines mean, but there are always new ones showing up as new software is written.

They’re more-likely to be useful if something breaks and then you go examine a specific, suspicious-looking message and learn what it means. You probably won’t be constantly trying to stay up on all kernel subsystems.

You have to have a thin client device to access the servers out on the Internet, which is…kind of what a sub-$500 low-end PC or budget smartphone would be.

I suspect that it’s more that a lot of people are going to defer upgrades at the low end of the scale, use an older device for longer than they otherwise would have.

Might not be great for security; smartphone OSes won’t get security updates after N years, and Windows 10 is EOL.

The HC1 chip doesn’t load model weights from memory. It etches them directly into the transistors. Every weight becomes a physical circuit.

That’s one way to avoid memory bandwidth constraints!

https://en.wikipedia.org/wiki/After_Dark_(software)

A 3D version of the toasters featuring swarms of toasters with airplane wings, rather than bird wings, is available for XScreenSaver.

That being said, it looks like xscreensaver doesn’t presently fully work on Wayland (or didn’t as of six months ago):

https://www.jwz.org/blog/2025/07/xscreensaver-6-11/

XScreenSaver 6.11 is out now. This is a Unix-only release – this version contains preliminary support for Wayland.

This is maybe not entirely ready for prime time, but I figured I’d get it out there so that some people who actually understand Wayland can poke at it.

System 7 stuff is going to look very small at 2026 screen resolutions. The widget dimensions on it mostly correspond to the original Mac’s dimensions, from 1984.

That being said, it looks like archive.org has archives of kaleidoscope.net’s — the most popular third-party theme engine — theme archives:

https://web.archive.org/web/20140423004746fw_/http://kaleidoscope.net/schemes/completelisting.shtml

So in theory, somone could make a bulk converter from System 7 themes to GTK or whatever.

checks

https://www.gnome-look.org/browse?cat=135&ord=latest&tag=macos

There’s an “Mac OS” category of GTK themes on gnome-look.org, and I imagine that the KDE people probably have something comparable. I haven’t used any myself.

https://www.youtube.com/watch?v=xnWKz7Cthkk

Killing a Toyota Part 1 | Top Gear | BBC

https://www.youtube.com/watch?v=xTPnIpjodA8

Killing a Toyota Part 2 | Top Gear | BBC

https://www.youtube.com/watch?v=kFnVZXQD5_k

Killing a Toyota Part 3 | Top Gear | BBC

On Wayland, it’s really a compositor rather than an X11-style window manager. Has to handle more tasks.

Though it looks like the River compositor is trying to reintroduce the window manager paradigm.

It sounds like it has experimental support as of six months ago.

https://itsfoss.gitlab.io/post/cinnamon-60-release-debuts-experimental-wayland-support/

Cinnamon 6.0: A Bold Leap Forward with Experimental Wayland Support

Last update – 2025-08-12