notabot

Which is why you end the fight before it starts. The greentext got lucky but by reacting oddly enough to make the robber pause then leaving they did the right thing.

I've been in a similar situation except I punched the thief before they drew the knike and then left. The fact he was obviously high as a kite probably helped. Ultimately, a knife fight between two sober, focused opponents, who are intending to kill or seriously injure will likely end as you suggested, but it the aggressor isn't actually ready to fight the fight can be avoided, or ends up much less lethal.

Ah, ok. You'll want to specify two allowedip ranges on the clients, 192.168.178.0/24 for your network, and 10.0.0.0/24 for the other clients. Then your going to need to add a couple of routes:

• On the phone, a route to 192.168.178.0/24 via the wireguard address of your home server
• On your home network router, a route to 10.0.0.0/24 via the local address of the machine that is connected to the wireguard vpn. (Unless it's your router/gateway that is connected)

You'll also need to ensure IP forwarding is enabled on both the VPS and your home machine.

Sort of. If you're using wg-quick then it serves two purposes, one, as you say, is to indicate what is routed over the link, and the second (and only if you're setting up the connection directly) is to limit what incoming packets are accepted.

It definitely can be a bit confusing as most people are using the wg-quick script to manage their connections and so the terminology isn't obvious, but it makes more sense if you're configuring the connection directly with wg.

The allowed IP ranges on the server indicate what private addresses the clients can use, so you should have a separate one for each client. They can be /32 addresses as each client only needs one address and, I'm assuming, doesn't route traffic for anything else.

The allowed IP range on each client indicates what private address the server can use, but as the server is also routing traffic for other machines (the other client for example) it should cover those too.

Apologies that this isn't better formatted, but I'm away from my machine. For example, on your setup you might use:

On home server: AllowedIPs 192.168.178.0/24 Address 192.168.178.2

On phone: AllowedIPs 192.168.178.0/24 Address 192.168.178.3

On VPS: Address 192.168.178.1 Home server peer: AllowedIPs 192.168.178.2/32

Phone peer: AllowedIPs 192.168.178.3/32

The big stumbling block I see with this approach is that it's not just the maintainers who do the work, as others also contribute code fixes, documentation and help in the community.

I can see the very real need to support the core maintainers on the projects we use, but I can also see that causing friction if the others who contribute to a project being successful and useful are overlooked. I know that some projects' communities put bounties on bugs they want dealt with, which helps to a degree, but still leaved many contributors effectively donating their time whilst a core group get paid. For instance, I've submitted and had accepted several patches across several projects that I use. They've usually been tobadd functionality that I wanted and saw others wanted too. I don't think I'd want paying for them, but I'd probably feel different if I knew the person accepting the pull request was being paid, either commercially or via a scheme like this. Maybe that will work out in practice, but I'd be worried about the change in dynamic.

I don't have a good solution to this, but I thought i'd offer it as a different viewpoint.

I haven't had any issues painting most plastics with the general hobby type spray paints. I know there are some that'll fail or damage the surface, but I've had good results with Plastikote (other brands are available, etc).

I should probably have been more specific about using spray paints for plastics rather than general ones.

Maybe a good pair of headphones and the careful application of some spray paint? Mask and holes or areas you don't want to colour, then apply several light coats until suitable pinkness is achieved. I suspect you'll get bonus points for personalisation.

They sound usable enough. If you're interested in it, have you considered running a LLM or similar? I think they cluster. If they've got GPUs you could try Stablediffusion too.

Mind you, at that price point I think we're past the point of just thinking of them as compute resources. Use them as blocks, build a fort and refuse to come out unless someone comes up with a better idea.

It really depends on what sort of workload you want to run. Most programs have no concept of horizontal scaling like that, and those that do usually deal with it by just running an instance on each machine.

That said, if you want to run lots of different workloads at the same time, you might want to have a look at something like Kubernetes. I'm not sure what you'd want to run in a homelab that would use even 10 machines, but it could be fun to find out.

That's fair, but the result seems to be the same; he's nowhere near as caustic when interacting with people as he used to be. I had quite a lot of sympathy with the message in most of his technical rants, but the delivery was counterproductive. If he's changed that I think he's done well.

I think even he realized his tocicity was a problem a few years ago, so he took time out to work on that and seems much more balanced now.

Sorry for th slow answer, I've been away. There is a way, if it's still useful to you:

First, create a named fifo, you only need to do this once:

mkfifo logview

Run your rsync in one pane, with a filtered view in the second:

tmux new 'rsync ...options... |& tee logview' \; split-window -h 'grep "denied" logview'

Replace ...options... with your normal rsync command line.

That should give you a split view, with all the normal messages on the left, and only messages containing 'denied' on the right.

The |& makes sure we capture both stdout and stderr, tee then writes them to the fifo and displays them. split-window tells tmux to create a second pane, and display the output of grep.