I dont use the outproxies for ssh, but it should be possible to connect to my server using its clearnet address using one of the outproxies. I have i2pd running on my server 24/7, and an entry in the tunnels.conf file that points to 127.0.0.1:22 on the server. When I want to connect to it, Ill run another i2p router on whatever device im connecting to, and Ill put the ".b32.i2p" address into ssh while using the SOCKS proxy for it. It is possible to make a client entry in the tunnels.conf on whatever device you are connecting from, and you can even turn the hops down to 1, which will increase performance, but lower anonymity. I think by default the SOCKS proxy uses 3 hops, but it can be changed.

But it should totally be possible to run your own private VPN over i2p, but Ive never done it myself, I just use ssh to port forward all of my self hosted stuff.

There are exit nodes in i2p, but they are called outproxies. The most popular ones are exit.stormycloud.i2p, purokishi.i2p, and outproxy.acetone.i2p. To setup an outproxy, you will have to setup software external to i2p, i2p routers by themselves will never exit. It is possible to visit onion domains inside of i2p, StormyClouds's outproxy has support for this, but from what ive heard, its recommended to use none of these, and to just use the tor browser if you need to access onion sites or the clearnet anonymously.

There are many use cases for i2p besides eepsites and torrenting, pretty much anything that runs on TCP can prolly be ran on i2p. For example, I run my servers ssh over i2p, so if my ip address were to change for whatever reason, the i2p address will remain the same. There are also IRC services, internet radio stations, there are even 2 public Minecraft servers.

Nheko is my favourite client, it uses QT and is written in C++, its lightweight and works well on my machines with low resources, it also respects my system theme

sudo sed -i 's/libalpm.so.14/libalpm.so.15/g' /usr/bin/paru

I made this userscript to put the vote count in comments back beside the vote button because the new one is kind of hard to see, its not the prettiest script (idk much about javascript), but I've tested it in Librewolf with Violentmonkey and it does work, hope it helps someone else!

// ==UserScript==
// @name        New script blahaj.zone
// @namespace   Violentmonkey Scripts
// @match       https://lemmy.blahaj.zone/post/*
// @grant       none
// @version     1.0
// @author      -
// @description 8/24/2024, 3:32:47 PM
// @run-at      document-idle
// ==/UserScript==

function main ()
{
	var parent_comments = document.getElementsByClassName("comment list-unstyled"); 
	for (var i = 0; i < parent_comments.length; /*i++*/)
	{
		/*console.log(i);*/
		var comments = parent_comments[i].getElementsByTagName("article");
		for (var j = 0; j < comments.length; j++)
		{
			var upvote_button = comments[j].getElementsByTagName("button")[1];
			
			if (upvote_button.attributes["vote_count_patched"] != null)
			{
				i++;
				continue;
			}
			
			var post_votes = upvote_button.attributes[2].textContent.split(' ')[0];
			upvote_button.append(' ' + String(post_votes));
			upvote_button.attributes["vote_count_patched"] = true;
			i++;
		}
	}
}
/*var mutation = null;
var mutation_observer = new MutationObserver(function(m) { mutation = m; console.log("new mutation logged yo");} );
mutation_observer.observe(document, { childList: true, subtree: true }); */

var mutation_observer = new MutationObserver(main);
mutation_observer.observe(document, { childList: true, subtree: true});

main();

I think it kinda looks like a lollipop

I think its just the non-exit nodes that are needed as long as the traffic stays inside the tor network, I dont think an exit node gets involved at all, but I'm not 100% sure

I think staying inside the tor network helps reduce the load on exit nodes, which helps all tor users who need to access the clearnet. I think there is even a HTTP header that can be put on the clearnet site that will put a button on the tor browser that tells users that there is a onion available.

What a bunch of cringe edgy antinatalist nonsense. Think about the future, if you don't have kids, who are we gonna feed to the machine a few decades from now?

I figure that the administrators of your homeserver could see your IP address, I doubt that it would be sent to anyone you are just chatting with.

Ive only had to setup a nvidia system once, so I might be missing some packages, but I think pacman -Rns nvidia nvidia-utils lib32-nvidia-utils should get rid of all of it.

WARNING: doing this will absolutely DESTROY YOUR SYSTEM, PERMANENTLY!!!

But if you wish to continue, you can erase all the EFI variables using the rm utility, I dont think you will be able to completely zero out the chip on the system from inside of Linux as its read-only.

But to delete all the EFI variables, cd into /sys/firmware/efi/efivars, if this directory is not availiable, either the efivarfs is not mounted, or you are booted in legacy BIOS mode. But once you are in this directory, run chattr -i ./* as root or sudo to remove the immutable bit on all the files, then run rm ./* as root. This WILL break your system. Only do this if you know how to restore your system using like a chip programmer.

This happened to me too. I had to grab the box that comes up and resize it like I would with a normal window, mine glitched a lot when I tried it, try resizing it as far as you can, it will try and glitch back, but just keep fighting it until it becomes a usable size, then log out of Plasma and log back in, and then you can size it back down to a normal size. Hopefully there will be an official fix for this soon

What about something like this:

for i in /media/johann/5461-000B/DCIM/100MEDIA/*.AVI; do newpath="$HOME/Public/240321/$(basename "$i" | sed 's/^IMAG/240321_/g')"; ffmpeg -i "$i" -ss 00:00:00 -t 00:00:20 "$newpath" && rm "$i"; done

If its just / owned by the mint user, you should just able to run chown root:root / as root/sudo, dont use -R. This should make root become the owner of /. Now if all files and directories in the partition are owned by the mint user, this might be a bigger problem

Alright, could you see what the root variable is in the grub console before manually setting it by running echo $root, and if it prints anything, could you run ls / in the grub console and see if you see like home dev etc, or the directories you would expect to see in / inside linux, and if you do see anything, could you run ls /boot/grub/ and see if you see grub.cfg. But if you are already inside linux, go ahead and install grub with --removable, it wont overwrite your current installation. I dont want you to format the efi partition, incase something goes wrong and you wont be able to boot into linux at all

I think anything that can be done with a fresh format can be done with the current one, when you ran grub-install after the issue with not running it as root, did you only do it with --removable? If so, the old grub is might be getting picked over the new grub installed at the removable fallback path, because it has a proper entry in the boot order. I dont know what key it is on your system, but if you can get into the boot order menu where it shows all the different boot devices, like where you can pick where you want to boot from, id look for one that just says something like "UEFI boot " or something like along those lines, it wont say like grub or your distro name, if there is such an option available, could you try booting from that option?

Oh its no worries, it sounds like you just need to regenerate the grub config, you can do this by running

sudo grub-mkconfig -o /boot/grub/grub.cfg

or if your distro has it, you can just run

sudo update-grub

then grub should see the config on boot and put you in the normal graphical menu

This is definitely strange, but the EFI system partition will have to be mounted to install grub to it, maybe the disk got mounted as read only, could you try explicitly mounting it as rw with this command

sudo mount /dev/nvme0n1p1 /boot/efi -o rw

and then see if you can make a file as root by doing

sudo touch /boot/efi/test

if it doesnt fail on a permissions error, try installing grub again with --removable incase this error has something to do with it trying to tell the firmware what disk to look in like this

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable

hopefully this will run without error and install grub, and if it does id run it again without the removable flag