My kids have a pile of cardboard screws that they use to turn boxes into all sorts of things; rockets, forts, cars and you could probably make organizers, shelves and the like too. The screws grip the cardboard surprisingly well, and it’s easy to make even quite large structures robust.
No, you cannot meaningfully delete your posts or comments, but that’s not because of any issue with lemmy, but because you posted them publically. They will be archived and indexed in other services.
It is always best to remember that all your activity here is public, and will be linked to your username. Given that, you may wish to minimise any personally identifying information you post, and use several accounts to split up your activities by topic.
The username associated with every vote, up or down, is available through the ActivityPub API. If your instance doesn’t show them (and I believe lemmy instances don’t by default) some helpful soul has built a tool to view them. Sometimes it fails for reasons unknown, but it lets you see who’s up or down voted a particular post or comment. I believe nom-lemmy interfaces like kbin also show you that information.
Clearly fake, it says there’s a tty number in the top left corner and there isn’t.
We fix it with rockets. Circularize the orbit and set it to an integer number of days that’s divisible by 28.
That only gives you 364 daya per year and we need just fractionally less than 365.25. You end up needing an extra day every year, and if we want to keep midnight in the middle of the night, and extra full day every four years (except when we don’t). Adding those sorts of bodges onto an otherwise elegant system would be awful to work with.
Instead, I propose we build giant rocket engines pointing straight up on the equator, and adjust the Earth’s orbit until one orbit around the sun takes exactly 364 days.
Well, that’s just bleak.
The way I look at it, parent processes know they will outlast their children unless they deliberately turn them into daemons, traditionally by double forking them. Daemons live on, even when the parent dies.
SIGKILL again? That implies it’s been KILLed before and either survived, or come back. Either way, we don’t like zombie processes in these parts.
/me fetches the really big process remover/cattle prod.
Before you can decide on how to do this, you’re going to have to make a few choices:
Theres two main ways to expose a git repo, HTTPS or SSH, and they both have pros and cons here:
HTTPS
A standard sort of protocol to proxy, but you’ll need to make sure you set up authentication on the proxy properly so that only only thise who should have access can get it. The git client will need to store a username and password to talk to the server or you’ll have to enter them on every request. gitweb is a CGI that provides a basic, but useful, web interface.
SSH Simpler to set up, and authentication is a solved problem. Proxying it isn’t hard, just forward the port to any of the backend servers, which avoids decrypting on the proxy. You will want to use the same hostkey on all the servers though, or SSH will refuse to connect. Doesn’t require any special setup.
Git is a distributed version control system, so you could replicate it at that level, alternatively you could use a replicated file system, or a simple file based replication. Each has it’s own trade-offs.
Git replication
Using git pull to replicate between repositories is probably going to be your most reliable option, as it’s the job git was built for, and doesn’t rely on messing with it’s underlying files directly. The one caveat is that, if you push to different servers in quick suscession you may cause a merge confict, which would break your replication. The cleanest way to deal with that is to have the load balancer send all requests to server1 if it’s up, and only switch to the next server if all the prior ones are down. That way writes will alk be going to the same place. Then set up replication in loop, with server2 pulling from server1, server3 pulling from server2, and so on up to server1 pulling from server5. With frequent pulls changes that are commited to server1 will quickly replicate to all the other servers. This would effectively be a shared nothing solution as none of the servers are sharing resources, which would make it easier to geigraphically separate them. The load balancer could be replaced by a CNAME record in DNS, with a daemon that updates it to point to the correct server.
Replicated filesystem Git stores its data in a fairly simple file structure, so placing that on a replicated filesystem such as GlusterFS or Ceph would mean multiple servers could use the same data. From experience, this sort of thing is great when it’s working, but can be fragile and break in unexpected ways. You don’t want to be up at 2am trying to fix a file replication issue if you can avoid it.
File replication. This is similar to the git replication option, in that you have to be very aware of the risk of conflicts. A similar strategy would probably work, but I’m not sure it brings you any advantages.
I think my prefered solution would be to have SSH access to the git servers and to set up pull based replication on a fairly fast schedule (where fast is relative to how frequently you push changes). You mention having a VPS as obe of the servers, so you might want to push changes to that rather than have be able to connect to your internal network.
A useful property of git is that, if the server is missing changesets you can just push them again. So if a server goes down before your last push gets replicated, you can just push again once the system has switched to the new server. Once the first server comes back online it’ll naturally get any changesets it’s missing and effectively ‘heal’.
I manage all my homelab infra stuff via ansible and run services via kubenetes. All the ansible playbooks are in git, so I can roll back if I screw something up, and I test it on a sacrificial VM first when I can. Running services in kubenetes means I can spin up new instances and test them before putting them live.
Working like that makes it all a lot more relaxing as I can be confident in my changes, and back them out if I still get it wrong.
How do such people program?
They don’t. They used to copy and paste stuff they found on the internet, then when it doesn’t work they made a barely coherent post on Stack Exchange, or maybe the issue tracker of one of the packages they think they’re using. I suppose that nowadays they copy and paste whatever they get out of the LLM de jour, then try to tell it that it didn’t work, copy and paste the answer and repeat until it either compiles or they finally give up and post to an issue tracker.
Canaries were taken into coal mines to warn the miners of poisionous gasses by dropping dead. When the canary metaphorically picks the lock on its metaphorical cage and literally makes a break for the border, I think you can consider that a sign of a similar magnitude.
It just occured to me that if you want to use Ubuntu without snap, you could uninstall the snap package itself (I’m not on Ubuntu, so you might need to find it), then put a ‘hold’ on the package to prevent it being reinstalled. That should, in turn, prevent any package versions that use snap from being installed.
Initially uninstalling snap might require removing any packages that use it, but that’ll tell you what you need non-snap versions of.
I suspect that what’s happened is you installed the apt version, then at some point upgraded it and there was a version in the main repo that had a higher version number and installed the snap version. If two repositories both have a package with the same name, and no other rules in place, the higher version number wins.
If that is the case, you need to pin the firefox package to the mozilla repository. You can find more details here: https://wiki.debian.org/AptConfiguration
You dismiss the data you recorded because it doesn’t seem to support your hypothysis tgat there is greater lag in wayland, but that’s not really the right approach, and I think it points to a different conclusion.
You recorded a lag of 5 or 6 frames at 90 frames per second in both Xorg and wayland, which suggests that the lag is the same to within 0.011 seconds, and I don’t think that you can say that’s a huge difference. However, what you didn’t test is the acceleration curve on mouse movement. If that curve is different under wayland it could easily feel infuriatingly laggy without actually showing any extra delay on the movement starting or ending.
I’m not sure how you’d accurately test that, a HID device just sending mouse move events wouldn’t do it as wouldn’t mimic you accelerating the mouse from stationary, so wouldn’t exercise the acceleration curve in wayland. You might need a physical device that moves your actual mouse a fixed dustance and then measure the distance the cursor moves on screen. Repeat for different movement speeds and you might have sone useful data.
Depending on exactly what you mean by importing from excel, there are libraries for Perl/Python/your scripting language of choice that will simplify that so it becomes a matter of a fairly small amount of code to build a test harness that does exactly what you want.
A dinosaur skeleton in a spacesuit.
Vim is running as you, rather than root, so you wont be able to edit other files as root, and any rogue plugins wont be able to either, which is good.
Sudoedit has various guards around what it’ll let you edit, in particular, you can’t edit a file in a directory you already have write permission on as doing so allows the user to bypass restrictions in the sudoers setup (there’s more detail in their issue tracker. If the directory is already writable though, you don’t need sudoedit anyway.
Be cautious of doing this with security sensitive files. When it copies the file and gives you ownership, any sensitive data in it is exposed to any process running as your user id, and and temporary fil£s the editor creates may also contain the sensitive content and be owned by you.
Walked across a room and pulled a muscle in my shoulder. It was painful enough that I could barely lift it for a week or so.