tal

This post just got inspired by (trying) to sign another receipt where the restaurant had a clogged ballpoint that would write only intermittently.

I don't carry a pen with me. Most extended text I work with these days is typed, so don't use one enough to really do so, but I have thought about doing so.

There are a couple of pen communities on Lemmy (which I'll mention below, for folks who might be interested). Thought I'd get a broader cross-section view of the general public, though; pen enthusiasts tend to have their own, often kinda niche, positions.

A few years back, I decided that I'd hit up an online pen store, get a variety of pens, and see what I liked.

In general, I've found that:

• Ballpoints are the most-common pen I see in the US. They use oil-based ink. They require a high amount of pressure to write with. They are inexpensive, don't smear, and don't bleed. And they are the only option if you need to use carbon paper, like on a check, due to that high pressure. But they are also exasperatingly prone to clogging, particularly on some receipts -- not sure if it's due to some sort of coating on the receipt paper. If you particularly like a given case, you can get non-disposable pens with semi-standardized inserts to "refill" a pen; these contain a replacement tip and ink container.

• Rollerball pens or gel pens use water-based ink. I'm generally pretty enthusiastic about them; they're probably my favorite as things stand, though I grew up mostly with ballpoints. They do have some drawbacks: they are more-prone than ballpoints to smearing (for those left-handed people out there who don't write right-handed and drag their hand through fresh ink when writing, I suspect that that's especially annoying). They're more-prone than to bleeding through paper (though this depends on on the paper and ink). However, my experience has been that they do much better than ballpoints when it comes to writing consistently without clogging. They also write much more-smoothly than ballpoints; the tip's interaction with the paper is closer to "gliding" over it, is less-fatiguing than writing with a ballpoint; many people find this to be a rather-pleasant surprise if they're used to ballpoints. Larger-diameter tips are even smoother. I have no idea why I see fewer problems with clogging with these, as intuitively I'd think that "water would dry out, and oil wouldn't". But, well, I just rarely see clogging with 'em, whereas with ballpoints, it's a near-universal. As with ballpoints, you can get semi-standardized inserts to "refill" a pen if you want a non-disposable. I would encourage most people to, if they have only used ballpoints in their life, to give a rollerball a try at some point; I was significantly happier.

• Felt-tip pens have a solid core through which ink moves. I used to think of these mostly as permanent Sharpies for writing on odd surfaces (thick, not something you'd write with), highlighters (again, special-purpose, not something you'd write with) or washable, large-diameter pens for kids doing coloring or something, again not what you'd write with. But I have had some narrow-diameter felt-tip pens, and they tend to work pretty well. They don't clog. They can dry out, if you leave them uncapped, but you can normally get even those going by adding a drop of water to the tip and letting the pen sit for a while. These do have some downsides -- if you let the tip sit on one place on paper, they tend to bleed through, since it keeps dispensing ink. That's not a problem with ballpoints or rollerballs. My experience is that they have more friction than rollerballs, don't have quite the "gliding" feel. You have a lot of options as to size of the tip, can get very large ones. For writing, you probably want a narrow one; these have a metal sleeve and just expose a bit of the felt at the end. Apparently it's possible, for some of these, to get refills, though I don't believe that it's common; these come in the form of liquid ink. Normally, I believe that these are disposables.

• Fountain pens. I really thought that these were entirely-obsolete, though they certainly have some ardent fans. I've read a lot from enthusiasts about how one should clean nibs, only store them in particular orientations, etc. However, on a whim, I picked up a package of cheap disposables. I then stored them in a hot car for years, didn't clean them at all, ignored storage orientation, did pretty much everything that I was told shouldn't be done with fountain pens. They wrote without a hitch. So I decided to give 'em more of a chance. These have something of a "gliding" feel, kind of like rollerballs. The tips are a bit more-fragile than rollerballs or ballpoints, can damage them by stabbing things. The big drawback: these guys are prone to bleeding through paper; having a sheet of blotting paper or maybe a clipboard beneath when writing to soak up any extra ink is a good idea, unless you've got more control than I do. I did pick up some thicker, more-expensive paper, and that helps a considerable bit, but obviously, if you intend to use only one type of special paper for writing, that's a pretty substantial constraint on pen use. They also tend to be more prone to smearing. Like felt-tips, as long as you keep the nib down, they'll keep dispensing ink, so you gotta train yourself to lift the nib if you're stopping movement. The big selling point with these, as best I can tell, is that you have an extremely wide variety of inks, and using non-disposable fountain pens that permit for refills is very common. Some people mix their own. The inks have various properties -- here's a page talking about sheen, shimmer, and shading -- that can let them create really visually-impressive effects. They can dispense all sorts of exotic inks that wouldn't work well in ballpoint, rollerball, or felt tip pens. I've never taken advantage of this, don't write enough for it, but I do think that it's neat; I have occasionally thought about picking up a fountain pen plotter, but don't think that I'd likely plot enough for it to be worthwhile. Looking at the state of plotters and printer manufacturers, which frequently use a razor and blades model for ink, I think that it'd be nice to just be able to get whatever consumables from whomever.

There are a few other kinds of exotic pens, like fudepens (or "brush pens") that are really more-interesting when doing stuff like East Asian lettering or some kinds of art, but aren't really what you'd want for writing in normal-sized Latin script. Or paint markers; also not really something you'd expect to normally write with.

In general, I found that I preferred larger tips. As long as I don't have to write in a too-confined space, ink flow with ballpoints and rollerballs was more-consistent and with them or felt tips, the writing was smoother.

As a kid, I used to use wood or mechanical pencils, but unless one needs erasability, I don't really feel that they stand up to pens. With wood pencils, one needs to lug around a sharpener. With either, the graphite tends to smear over time; fold up a paper with pencil writing and put it in a pocket, and it'll slowly blur to unrecognizability. And the graphite gets on things (and I'd just as soon not be having electrically-conductive dust being dumped everywhere).

For me, the big issue with going crazy on pens in 2024 is that I just don't use one all that much. Even a lone disposable pen will last me a very long time. But it is nice to still be able to write consistently when one does want to write, and I felt that I'd never really sat down and looked into the various options out there.

Since I think that it's worthwhile to mention relevant communities to help people find them, if they haven't yet:

[email protected]

[email protected]. Doesn't seem to be getting much traction.

[email protected]. No traffic.

[email protected]. Only a little traffic.

[email protected]. No traffic.

There are also some .ml-based communities; I tend to use non-ml-based communities in preference to .ml-based communities myself, but for those who feel otherwise, there are [email protected], [email protected], [email protected], and [email protected], none of which are seeing much activity.

A common task people want to perform is running a set of given programs during every Wayland session.

GNOME and KDE have their own approaches and graphical utilities for down this. For those of us who don't use a desktop environment, how about in Sway?

A bit of experimentation appears to show that this syntax is a pretty reasonable way to do this:

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

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

Thought I'd share for anyone else running into this.

For some Sway users, that may be enough. But if anyone wants to read more history, here goes!

Background and rationale:

Once upon a time, it was conventional to have a shell script, ~/.xinitrc, that was invoked whenever someone started up an X server with startx after logging in on an (initially) text terminal. Any per-session commands could be invoked here.

Later, when display managers showed up, it became common for a Linux machine to go straight to a graphical display at boot and show a login prompt from there. xdm showed up; if it was started, it'd run another shell script, ~/.xsession. A lot of people, including myself, just symlinked ~/.xsession to ~/.xinitrc.

Still later, some desktop environments, like GNOME or KDE or some less-popular ones, introduced their own schemes for storing a list of programs to start when the graphical environment came up.

Wayland+sway -- to my initial surprise and annoyance -- isn't really geared up for that. In theory, you can use whatever login manager you want. I use a non-standard login manager -- greetd to launch agreety (and I'd use emptty if it were in Debian bookworm) which lets me log in on a terminal. But these don't provide functionality to run a startup script. This kind of makes sense -- on X11, once the display manager starts things up, X11 can run programs, whereas Wayland really requires a functioning compositor to be going, which means that Sway really needs to be up and running. So maybe it makes sense for the compositor, Sway, to handle launching startup programs in the graphical environment, rather than the login manager. but Wayland compositors don't have even a semi-convention for a "login script" like ~/.xinitrc or ~/.xsessionor~/.xprofile` or an equivalent, which surprised me. That might be because Wayland compositors are heavier than their X11 window manager analogs, and perhaps its less-expected for people to be switching among them.

What Sway does is to, in its config file, ~/.config/sway/config, have two directives, exec and exec_always. One can make them invoke a script. These can be handy. But they don't quite what I'd ideally like them to do.

You see, Sway -- like some X11 window managers -- has the ability to permit a "reload", where it re-reads its config files. That's handy! If an X11 window manager couldn't do that, when you changed its config file, you'd have to close all your graphical programs, log out, and log in again to confirm that it did what you wanted. You don't have that problem with Sway. You can just change its config file, ask Sway to do a reload, and it'll be "re-applied". And then exec and exec_always come into play -- the former will run a program only when Sway initially starts, but not when it does a "reload". The latter will run a command each time, both at Sway start and each time Sway reloads its config file.

For some programs, exec and exec_always are sufficient. Maybe you just want to make sure that a program has been run and then terminated at least once in your current session.

But that isn't normally what I want to do. By far my overwhelming need -- and I suspect this is true of others -- is that I want to have some kind of daemon running and persisting in the background of my session.

Some daemons try to be clever. If you try to run multiple instances at once, the new instance will just bail out. blueman-applet is like this. And if your daemon works like this, then running exec_always is fine. If you run a new instance and there's an already-running instance, the new one will just bail out.

But some daemons don't -- they just start up another instance. So every time you reload your Sway config, exec_always will start another instance of that daemon. I have a couple of daemons like that. poweralertd notifies me when my laptop battery is getting low, for example. If I just let poweralertd do its own thing and start it via exec_always, then when my battery gets low, if I've reloaded my Sway config 5 times, I'll have 5 instances running, and get 5 warnings when my battery gets low.

But running exec isn't ideal either, because then you have to give up on Sway "reapplying" your config when you reload it. If I want to have a new daemon running in the background of my Wayland session, I don't want to have to log out to ensure that my config is working correctly.

Now, at this point, I suspect that a number of people think "Aha! What about systemd?"

So, not everyone is a huge fan of systemd. It is a very large software package that provides a lot of useful functionality to most present-day Linux systems. So you might not want to tie yourself to systemd.

But more-problematic -- while systemd does have the ability to manage both "system" daemons that run one instance per system, typically come up when the system does, and "user" daemons, one instance per user...that isn't quite correct for Wayland. It's reasonable for a user to have multiple concurrent Wayland sessions on a Linux machine. Maybe it might make sense to selectively share some functionality among those, like one mpd instance to play music -- dunno about that. But you definitely don't want to have random Wayland programs run in each session running one-instance-per-user, because otherwise, any additional Wayland session will have the programs just not come up in that new session.

It looks like some people out there have recognized that this is an issue. uwsm looks to my quick glance at being a stab in the direction of "per-Wayland-session systemd-based management". But whether-or-not it could be used, it's not in Debian bookworm, and I want to use stock software for basic stuff like getting my desktop up on a new system.

Hence, we get to the above flock-based approach. So, let's say that one wants to have a program like wl-paste running persistently, but only one per-session. How?

We want to have only one instance running at once. Traditionally, the way to achieve that on a Unix system is to create a file, then establish a "file lock" on it via the flock(2) function; this is guaranteed by the OS to be an atomic operation, only one can occur. There's a command, flock(1), which does all this at one go -- it creates a file if it doesn't exist, establishes a file lock on it, and then, while continuing to run, runs a specified command. When a process goes away, the OS releases the file lock, so when the invoked command (here, wl-paste) exits, the flock process exits, and the file lock goes away. By default, flock will block if there's a lockfile with a held lock, which is what you want if you just want to make sure that two commands wait to avoid interfering with each other but with -n, it'll just fail; this is the behavior you want if you want to make sure that you have one, but only one, daemon active.

And we want to have one instance per session, not per user. The $XDG_RUNTIME_DIR environment variable provides a temporary directory per-user...but not per session. $WAYLAND_DISPLAY is guaranteed to be unique per session for a given user. So any path containing both $XDG_RUNTIME_DIR AND $WAYLAND_DISPLAY is going to be unique per-session; we just need an extra bit of text ("-poweralertd") to make it unique to a given daemon per session.

Given how this wasn't an immediately-obvious approach to me, thought that I'd point it out to anyone else who might be using Sway and want per-session daemons running.

I've got a high opinion of Michael Kofman's commentary on the Russo-Ukrainian War, consider him to be one of the better commentators talking about the matter to follow; for those not familiar, Kofman's a Ukrainian-American analyst specializing in the Russian military. A while back, he started doing a regular podcast with War on the Rocks called The Russia Contingency; they just came out with a new episode, the first I'm aware of where he's talking about the Kursk offensive. They don't do transcripts, but I thought I'd listen to it and type up a summary for anyone interested who may not like the podcast format.

This also has Dara Massicot, a coworker of his who he also sometimes does interviews or panel discussions with. Both are currently at the Carnegie Endowment for International Peace; when I started paying attention to him, Kofman was at the Center for Naval Analyses and Massicot was at Rand.

I personally particularly like Kofman's tendency to focus on highlighting what factors are likely to be or become significant, something that I don't see a lot of well-informed people putting online. I'd call his stuff generally well-informed and objective.

This is was released August 10, so it's about a day or so old, and the situation is obviously rapidly-evolving.

I've done these transcripts before, and have tried to get placenames and such correct, but I do not speak Ukrainian or Russian, so this is my best-effort attempt to try to provide references to placenames and people using maps and what resources I can find online (Google Maps, Deep State Maps, ISW's maps, etc). I may get things incorrect; that's on me and my own limitations. Kofman's stuff tends to be pretty information-dense, so usually my summaries of his stuff head closer to being transcripts.

Summary:

Kofman

• Major caveat: Operation started August 6, so about 4 days of activity so far. Most material in this environment tends to show up about a day or two days after happening, so anything publicly-known is going to be dated by about a day or so.

• Ukrainian regular forces have pushed in from Sumy into Russia's Kursk Oblast. They seem to have seized the town of Sudzha. They pushed northwest towards the town of Snagost and are outside Kremyanoye further northwest. They've advanced north; it's unclear how far, but maybe several settlements down the road towards Liubimovka and Kursk itself. Also made several salients advancing branching down roads coming from it. At this point, from open source material, statements that Ukraine has captured maybe 350 square km, probably more by now, but Kofman does not expect that all of this territory is yet controlled, or that it's early to make that determination. [I expect that this is due to it including areas between roads where Ukrainian forces have no physical presence.] It is also not clear yet what they intend to hold. There is definitely a salient that they have made; they overran the border guards and the initial conscript units that were there. They took quite a few POWs; we do not know how many, but most likely in the hundreds. Ukrainian forces advanced quickly, but also important to remember that advance forces entering territory is not the same as controlling territory. A lot of speculative maps floating around out there from various people trying to put together a picture of what's happening.

Massicot

• Agreed. Not yet clear whether municipal buildings are controlled, what is the status of the local police force, is it only roads that are being moved up, how are they holding behind those. Believe that who are prisoners may have political significance for the Kremlin; this has been a sensitive political topic for Putin for some time, that conscripts not be involved. I'm also watching who Russia is looking to blame for this, and has been shifting around but looks to be the Chechen Akhmat group [Kadyrovites], that they were supposed to defend but ran away or couldn't close. In general, a lot of movement right now. When I see advancing maneuvers like this, have to ask what is the logistical plan; how are the forces going to be resupplied and refueled. That information is not visible to us right now. Lots of footage online of things exploding, but important things, things that Kofman and I follow, like where are the reinforcements, what are the logistics plan...that's the key part to watch for right now.

Kofman

• Very clearly not like the previous raids organized by HUR [Ukrainian military intelligence]. This is an operation clearly planned by the Ukrainian general staff. Operation composed of regular forces, probably supporting elements from Ukrainian national guard, maybe territorial defense, and Ukrainian border service. From what people have been able to identify, there are elements of at least five different brigades. I want to be clear about this: elements. Sometimes when people see brigade numbers, they assume that all of the brigade is present. That's not always the case. As best as Kofman can tell, this operation maybe involves something like a divisional-sized element, maybe best guess ten to fifteen thousand men. It doesn't look that large. Kofman doubts that what we're seeing is just the tip of a spear, for a couple of reasons. First, a number of these brigades were moved off the line in Donetsk and other areas. A couple of them are brigades that had been recently-created and were going to serve as a reserve. Based on what Kofman's seen while doing fieldwork in Ukraine, there isn't a great deal of excess manpower or additional brigades available for this sort of operation, so not likely that Ukraine has a lot of free forces to throw into this without having to pull them off the line. A number of these units were pulled off the line; elements of 80th Air Assault Brigade, 82nd Air Assault Brigade, 22nd Separate Mechanized Brigade, probably have some elements of 95th Air Assault Brigade, maybe 5th Separate Assault Brigade as well, along with all sorts of supporting elements, maybe one of the newer 150-series brigades like 150th. Bottom line, in terms of operation size, it's probably closest to the Ukrainian offensive in Kharkiv in 2022. It looks like it's following a similar template. That's not surprising, given that Syrskyi's in charge. I believe that initially they were quite successful and had a significant breakout. My first reaction is that this looks deeply-embarrassing for Russia. I don't know what you have to do to get fired if you're Gerasimov, your favorite general, not sure what it takes, but...laughs

Massicot

• I'll say this. If Surovikin was still involved in this, he would have built defenses and minefields on the other side of the border.

[From my past listening to Kofman's material, he has generally been critical of Gerasimov's performance relative to Surovikin's; he considered Surovikin's more-defensive-minded approach to be more dangerous for Ukraine, as it would force Ukranian forces to deal with Russian defenses in an attritional conflict, that Gerasimov's attempts to conduct offensives into strong Ukrainian defenses unwise and likely done for political reasons, at Putin's behest, due to Putin wanting to gain ground.]

• Would guess that there are also units subordinate to HUR and SBU [Ukrainian intelligence agencies] involved in scouting things out in advance parties at start of offensive last week.

• Share concerns with Kofman about Ukraine's ability to reinforce, and Ukraine pulling people off the line may make situation elsewhere more-difficult.

• In terms of logistics, access is probably okay, but not sure what happens to logistics tail after it crosses the border to try to catch up with the guys who are all the way forward.

[Note that the border crossing being used is apparently the R200 -- Google Street View. This is a single two-lane road, and there does not appear to be a rail route through.]

• Is embarrassing for Russia. Still in initial stages; don't know how this is going to end, but for the first week, this reveals a lot of problems that shouldn't be present on the Russian side two years into a war. Right when the war started, Russia declared a state of emergency, modified martial law in all of the regions that bordered on Ukraine; this was one of them. What that does is gives local law enforcement and military enhanced power to set up curfews, set up roadblocks, to put in minefields, to do territorial defense things specifically to make it easier to defend when you're at war with your neighbor. The fact that we're two-and-a-half years into this and either Russian intelligence did not pick this up, which is a failing, or it went up to General Lapin, who commands this area, and then went sideways, or it went above him up the chain to Gerasimov. [Note: I have seen later news coverage that they did detect Ukrainian concentrations, that it reached Gerasimov, but that Gerasimov did not consider it significant and did not inform Putin about it.] Not clear to me yet who will bear ultimate responsibility. I think it falls on Lapin, who is in charge of border defense in this region, and seems to be some effort to blame Akhmat Group. You start to see appeals from Russian citizens, and expect them to become politically-damaging to the Kremlin. You start to see them...if you haven't seen them, they look like "we have supported the war for two-and-a-half years, we are a border town, our men are off fighting, and you haven't evacuated us, you're not providing for us, there's no help, this is dangerous and unfair". This is a dangerous message for the Kremlin to let bounce around in the information space.

Kofman

• We need to look at how this began. It is clear that Ukraine managed to achieve operational surprise. To be clear, folks like me didn't know that this offensive was coming. I don't think anybody did. I don't think that they told the United States or others. I have my own clear-cut theory as to why: my view is that tactically, Russia has actually had ISR coverage. There are videos posted of Russian drone feeds of them watching Ukranian forces before they crossed the border and as they were crossing the border. But as these types of operations continually show, war is a human endeavor, and technology may make the battlefield a lot more transparent at the tactical level, but people make mistakes, they don't prepare for things like this, they don't react in time. In some ways, it's not unlike what happened during the Kharkiv offensive, which people tried to portray as a surprise. In actuality, Russians were talking about it for two weeks during the buildup before Ukraine conducted it, and the Russian general staff just didn't respond or appropriately prepare or whatnot. I'm glad that you mentioned this; we continue to see Russian forces continue to make some of the same types of mistakes. And there are reasons for that. First, Russia seems to do quite poorly when it has to respond dynamically in a situation like this. So to some extent, you see Ukrainian units having the run of the place in these initial four days. Russian forces do far better when they're operating with a prepared defense, fixed lines, more in positional warfare. Much harder, as best I can tell, for them to coordinate action between different types of units. That still remains fairly weak, and it's interesting to observe. The other big issue is "what do you have to respond with"? Russia clearly has reserves, it has second-echelon units, it can pull units off from, say, the Kharkiv axis if it needs to. The issue you get, typically, is that newly-generated units are inexperienced. They also often aren't led by people who are that experienced. They will typically perform poorly against experienced units. This has been the case on both sides. Ukraine has had the same experience. Whenever it's thrown a battalion from a brand-new brigade to try to hold a part of the line...it's been fairly-consistent in this war. So when you have to send a reinforcement, and all your experienced units are on the front, your options are going to be newly-contracted personnel, or, worse, a battalion that's primarily conscript-staffed. And they're going to be very unprepared, and you're going to see things like we saw yesterday, which is an entire Russian column of trucks filled with infantry parked somewhere on a road essentially getting wiped out by a HIMARS strike. They probably lost a company's worth of men. That's the kind of mistake that the Russian forces along the line of control typically don't make. But it's definitely the kind of mistake that new units do make and will consistently be making when they're sent to reinforce and try to respond to this type of situation.

Massicot

• Agreed. When we think about that region, who might that be? Russia has several regeneration and training sites that are north of that area. They've probably pulled whoever was closest and was reasonably-available to do this, which is why you see that clumping. When I saw the drone feed of the POWs surrendering, that is really inconsistent with a lot of what we've seen inside occupied Ukraine from units who have been fighting for years. They typically don't surrender. Ukrainians will say this, we've seen it on drone feed, they'll shoot themselves in the chest or head with a rifle...they don't really surrender like that in an organized way. My first thought when I saw this was "are these conscripts?" But then I think, no, they were too big...I mean, men with muscles, 18-year-old Russian conscripts just have a different bearing and size. To me, this didn't seem like these were 18-year-old boys from a base. They were probably pulled from whatever training range was available, not experienced guys, and that's why you saw that. If these were hardened guys rotating out of the zone, what we've seen might have looked very different. The Russians are...presumably...it's not clear on how they're planning on responding to this, but they will, so I'd caution everyone that Week Two is going to look different from what we're sitting and looking at today.

Kofman

• Yeah, it could go a number of directions. The Russian offensive on Kharkiv looked quite good in the first couple of days, but actually culminated by around Day 5 or 6. This is a very different operation and situation, but these things tend to be quite dynamic early-on, but the offensive action can very quickly reach a culminating point. Depends on what you have to exploit it with, have you thought through the logistics, do you have additional reserves to throw in to sustain momentum. Ukraine has air defense there for example, but this is clearly a fairly-narrow incursion; we've already seen them lose some of their air-defense systems, FrankenSAMs and what-have-you, we've seen Russian Lancet attacks and attack helicopter missions. So it's clear that Russian forces are suffering losses and getting personnel captured. My best guess that the forces that you saw were probably territorial troops of some kind, reservists...conscripts tend to be very young, I think you're right there, but we don't know who that was. It might have been border guards. It might have been the formations they created -- and they created a whole bunch of them -- to help guard the borders against raids, but these are...I'm not sure that it'd even be fair to describe them as second-echelon troops in terms of who they likely staff that with. They clearly were unprepared to deal with an actual mechanized assault and a planned operation by regular forces.

• Let's talk about objectives. Here, we are sadly in the realm of speculation, but we should try to at least make some educated guesses. My first impression is that Ukraine likely would wish to trade any territory that they end up holding for Russian withdrawal from Kharkiv if they could. Alternatively, I think that the minimum objective here is to create a Krynky-type situation. For those who recall, Krynky was the lodgement that Ukrainian marines held for a very long time on the left side of the Dneiper River bank. Russian forces, particularly the Russian airborne, spent a long time trying to attack it. It cost them quite a bit in terms of losses. Ultimately, Ukrainian forces withdrew from it and abandoned that position. The purpose of a Krynky-type salient is that, of course, Russia would then have to throw a lot of forces at it since this is on Russian territory. The challenge is that for that to be successful...invariably Russia will be throwing in reserves. That's not even a guess; we've already seen that they've been moving reserves into the area to counter. The issue is that Ukraine pulled units off the line to do this and deployed units that were also what Ukraine had available in its reserve. The question now is whether Russia will deploy a substantially-larger force to counter this; will it be worth it? What the balance of attrition will be. And most-importantly, is it going to force Russia to pull forces from active operations that will materially-affect its current advances in Donetsk around Pokrovsk or the current positions that they are holding in that narrow buffer north of Kharkiv? So far, the Russian advance towards Pokrovsk has not stalled; if anything, it has accelerated over the last couple of days. I don't know if that's going to hold; I'm just saying that that is one of the litmus tests in terms of what the operation can achieve. If it does, it'll be very successful. I've heard -- I've read in papers -- folks advancing the idea that it could be leverage for some future negotiations. I am very skeptical of that; I think that the operation probably has some kind of concrete, Day 1, 2, 3 objectives. Maybe there is a clear objective that they are trying to get to there. I don't think that it can be especially grand given the forces arrayed there and how difficult it's probably going to be to hold that terrain. I do think that any operation probably has minimal and maximal objectives, and that they can change depending on how it unfolds and that's why you can be both right and wrong in trying to guess what they are. Something can have been a planning objective for the operation, and then the operation becomes much more successful than anyone expected, like Kharkiv did in 2022, and then you get much-more ambitious and then you try to advance much more than you initially-intended, or alternatively, the operation is less-successful, and you pare down your objectives. Political leaders will invariably say that their initial objective is whatever the thing looks to have achieved.

Curious as to what people think has the most replay potential.

Rules:

1. The "desert island" aspect here is just to create an isolated environment. You don't have to worry about survival or anything along those lines, where playing the game would be problematic. This isn't about min-maxing your situation on the island outside of the game, or the time after leaving.

2. No live service games unless the live service aspect is complete and it can be played offline -- that is, you can't just rely on the developer churning out new material during your time on the island. The game you get has to be in its complete form when you go to the island.

3. No multiplayer games -- can't rely on the outside world in the form of people out there being a source of new material. The island is isolated from the rest of the world.

4. You get existing DLC/mods/etc for a game. You don't get multiple games in a series, though.

5. Cost isn't a factor. If you want The Sims 4 and all its DLC (currently looks like it's $1,300 on Steam, and I would guess that there's probably a lot more stuff on EA's store or whatever), DCS World and all DLC ($3,900), or something like that, you can have it as readily as a free game.

6. No platform restrictions (within reason; you're limited to something that would be fairly mainstream). PC, console, phone, etc games are all fine. No "I want a game that can only run on a 10,000 node parallel compute cluster", though, even if you can find something like that.

7. Accessories that would be reasonably within the mainstream are provided. If you're playing a light gun game, you can have a light gun. You can have a game controller, a VR headset and controllers, something like that. No "I want a $20 million 4DOF suspended flight sim cockpit to play my flight sim properly".

8. You have available to you the tools to extend the game that an ordinary member of the public would have access to. If there are modding tools that exist, you have access to those, can spend time learning them. If it's an open-source game and you want to learn how to modify the game at a source level, you can do that. You don't have access to a video game studio's internal-only tools, though.

9. You have available to you existing documentation and material related to the game that is generally publicly-available. Fandom wikis, howtos and guides, etc.

10. You get the game in its present-day form. No updates to the game or new DLC being made available to you while you're on the island.

What three games do you choose to take with you?

Quick background for anyone who doesn't use tmux or screen: both are utilities that run in terminal that provide a bunch of nifty functionality. The big ones are:

• The ability to disconnect from a remote host and reconnect via software like ssh or mosh, leaving the remote programs running. This also ensures that connection loss doesn't kill off remote programs, making it -- in my opinion, at any rate -- pretty essential for ssh, though mosh has more-limited built-in functionality.

• The ability to have multiple virtual terminals in one. There are a bunch of ways to do this (the Linux kernel has multiple ttys, X11 window managers or Wayland compositors can provide virtual desktops with different graphical virtual terminal programs running on each, and some virtual terminal programs provide a way to run multiple virtual terminals, usually in a tab or something). I prefer this route, though, because among other reasons, it works everywhere.

But they also provide a lot of other handy functionality, including things like file transfer via the terminal (well, screen does), logging of what the current terminal is receiving, copy-pasting using vi or emacs keybindings, a terminal-level "status bar", and such.

But I was doing work on my tmux config, and thought that I'd go over my ~/.tmux.conf, since it addressed a few things that annoyed me, and I figure that other people might have crashed into. Maybe others could share some of their neat tmux or screen stuff, if they're in the moon:

unbind-key C-b
set-option -g prefix C-o
bind-key C-o send-prefix

This sets tmux to use "Control-o" as the "prefix key", which it uses before all other keybindings. Out-of-box, both screen and tmux grab keybindings which conflict with very-common emacs keybindings, C-a (beginning of line) and C-b (previous character), respectively. Control-o is only used by (what I'd call) a fairly-obscure emacs feature, which you can still access by hitting Control-o twice. If you use vi keybindings (including in bash and other programs that use readline, which default to using emacs-style keybindings), probably not necessary. Been using this for many years, ever since screen; it's apparently a very common problem for new tmux and screen users.

set-option -g status-bg black
set-option -g status-fg cyan

By default, tmux uses black text on a bright green background for the status bar; while this shows up well, for me, at least, this is kind of overwhelming. I prefer light text on a black background, or "dark mode", as it's popularly called these days. On some terminals, blue is hard to read out-of-box, and while I generally try to tweak my terminals to get it readable, cyan (bright blue) avoids this.

set-option -g status-left '#I|#H #(cut -d " " -f 1-4 /proc/loadavg)'
set-option -g status-right ""
set-option -g window-status-format ""
set-option -g window-status-current-format ""

The default tmux configuration follows a convention where, for each "window" one opens, there's a visual indicator showing a per-window entry. This is a common convention that many GUI programs use (opening a tab per window). Emacs traditionally has not done this, the idea being that you should be able to have many buffers open, that screen space is a limited resource and that if you want to switch the content that you're looking at, you're better-off bringing up a full-screen, scrollable list. tmux can do this with prefix-key w out-of-box. If you have, say, ten open, there isn't gonna be space to show 'em all. So I pull that out.

I do want to see the host, to ensure that I don't confuse a tmux instance running on Host A running ssh in a window with sshing to Host B and running tmux there.

Tmux defaults to showing a clock, which I get rid of with the above. I already have a clock on my desktop, and I don't see much sense in throwing them elsewhere in each terminal. Tmux even defaults to showing a large one if you hit prefix-key t, though I can't imagine that many people use that.

The current loadavg isn't essential, but it's a useful bit of status that tells one immediately whether some program is either still doing work or running away.

I don't use window names: just numbers; so I hide names. It's normally obvious from looking at a virtual termainal what something is, and switching by number is faster by keystroke.

set-option -g update-environment "DISPLAY WAYLAND_DISPLAY SWAYSOCK SSH_AUTH_SOCK"

This updates the environment variables in a tmux session when re-attaching. Various programs don't do well if you detach from one session, log out of a graphical session, and then log in again; this fixes those. DISPLAY is for X11, WAYLAND_DISPLAY for Wayland, SWAYSOCK for the Wayland Sway compositor (if you use that), and SSH_AUTH_SOCK for ssh-agent, which remembers a password to unlock an ssh key for a while.

bind-key H pipe-pane -o "exec cat >>$HOME/'tmux-#I.log'" \; display-message "Toggled logging to $HOME/tmux-#I.log"

This sets up tmux to provide functionality that screen has out-of-box -- if you trigger it, it will start logging the output of the current console to a logfile in your home directory. Useful when you've already started a program and it's spitting out information that you need a copy of, or if you want it to not disable color output (something that many programs do when they detect that their output is connected to a pipe rather than a tty); with my settings, Control-o H will toggle logging for a given window.

# emacs-style keys
bind-key C-n next-window
bind-key C-p previous-window
set -g mode-keys emacs
set -g status-keys emacs

I like emacs-style keys rather than vi-style.

bind-key C-c new-window -c "#{pane_current_path}"

While tmux has a default keybinding (prefix-key c) to create a new window at the current working directory that tmux was started at, it has no binding to start a new window at the current working directory being viewed in a window at the moment, something I frequently want to do -- this makes prefix-key Control-c open a new shell at that point.

set -g visual-bell on

Beeping is obnoxious and in an open environment, can be disruptive to other people; many people switched to having their terminal flash rather than beep years back; many programs supported "visual bell", which is just flashing rather than playing a sound. It's not so bad these days, as Linux machines aren't typically playing irritating beeps out of on-motherboard speakers, but in general, I don't like having things beep.

Anyone else got useful snippets that they'd like to share that they use with tmux or screen?

Some California House Democrats don’t want the process to replace the president on the ticket to seem like a Kamala Harris coronation.