Read the message its telling you... go install has no -u flag.
$ go install github.com/nomad-software/meme
The new service includes a WiFi 7 router
I don't recommend it.
I would shoot for a 4 port 2.5Gbe unmanaged switch with 2 SFP+ ports (6 total ports) for 10G networking. 2.5Gbe is going to be more than enough for any WiFi solution you choose with room to upgrade 10G to WiFi if you wanted to spend a bit more on a higher tier WiFi router still leaving a single SFP+ port for 10G networking from your PC.
Biggest hit for your buck. Gonna set you back $40-50.
but if I ever wanted to get the max out of it, what does that take?
Kind of a lot. At least a top to bottom upgrade, from modem (PON), to 10G networking, to new Ethernet cables, to new 10G network drivers. Looking at a few hundred if you do it right. I also had Optimum's 8Gbps internet and was never able to even get anywhere near advertised speeds due to network saturation. IMO, the upgrade right now is too expensive to justify the expense for what you get. If you were confident you would be able to max out the connection, that would be a different story. But ultimately it's gonna be up to you. If you don't mind dropping a few hundred on upgrades, then go nuts.
Martin Luther King Jr’s accomplishments are nearly wiped out
Troglodyte. With 2 replies you've proven to be one of the most ignorant people I've ever experienced in almost 30 years online. You deserve a fuckin' award.
The motherfucker helped create the MMR vaccine... I would say he did do something. If you'd like to see somebody that's not do anything at all, look in the mirror you feckless ignoramus...
I mean Jesus Christ man. I don't think I've seen a comment this lacking in intelligence in my entire life. It would be like if somebody went to Martin Luther King Jr and said "well what are you doing about it!?" after he said that he was upset at the status quo.
It's just an unbelievably ignorant and moronic statement to make.... I can't even fully wrap my head around it--how you put absolutely zero forethought into that statement before making it.
I picture you as someone who drowns in the rain because they have their mouth open while they look up. Jesus Christ.
Then, anyone in the world can verify your signed statement using your public key.
Of course. The only barrier is the possession of your public key. I really don't understand what you're getting at here. Anyone with your public key can verify a PSK signed statement you made, which obviously is predicated on them having access to the key.
Anyone only has access to your public key if you give them access to your public key. So no, not really. They should have access to it. It's not something you should keep private, but SSH shared keys aren't PGP shared keys. There's no key servers for SSH shared keys.
Reasoning skills and experience. There are entire botnets dedicated to finding servers with open SSH ports on 22. If the bots can connect, the IP of the server will be added to a list to be brute forced.
I'm a per diem linux systems administrator. Right now I have a VPS that I setup myself. It uses a non-standard ssh port, fail2ban, and rejects incoming connections to port 22. According to connection logs, I get about 200 attempts per 24 hours from bots randomly pinging ports to see if they can catch an open SSH port--and they're banned via fail2ban.
I checked out some other servers that I manage, which I did not setup and have no control over how they operate. Sifting through just 3 random servers and checking connection logs, they have a combined 435,000 connection attempts in the past 6 hours between the 3 of them. These are relatively small servers with an extremely small presence. Simple fact of the matter is, is that they all have port 22 open and reachable. So botnets attempt to brute force them.
So just anecdotally that's a difference of 0.0459770115% or 99.96%. Anyone telling you that changing the default SSH port doesn't do anything for security has absolutely no practical experience at all. It significantly reduces your attack surface as bots have to guess at ports until they find your SSHd's operational port to even begin to start sending attempts.
This is TLS authentication via SSH, which is a completely different ballgame than using SSH keys for data encryption, decryption, and verification.
Mathematically, they're not even close to the same. How you could ever assert such an indefensibly and empirically incorrect statement is beyond my reasoning skills to understand.
PKC Key signing uses hashing algorithms like RSA, ElGamal, DSA, and ECDSA to create one way cryptographic hashes for given input data. The singular purpose of these signatures is to verify the integrity of data. Not to protect the data in any way whatsoever or to be reversed into clear text; again, the hash is one way.
PKC encryption uses encryption algorithms like AES, Blowfish, Twofish, PGP, and Diffie-Hellman to create reversible cipher text. The difference being, the cipher text of an encryption process can be reversed and represents the data itself.
All of this is clearly outlined in the RFC: https://www.ietf.org/rfc/rfc4880.txt
Encryption can only be done with the PGP public key. Even if you specifically use the private key, it contains the public key, and GPG already knows to use the public key for encryption. You cannot create encrypted cipher text using a GPG private key.
Likewise, you cannot decrypt data using the public key, nor can you sign statements with a public key. For those processes you must use a private key.
I had no idea people found GPG this confusing...
You seem to be fundamentally misunderstanding how the shared keys work, here. You don't get to choose which key you sign with, either private or public.
If you sign a statement, it uses your private key. Period. The methodology is only the original owner of the keys has access to the private key, so any signed statement also using that private key, is directly from the key owner. Alternatively, anyone has access to your private key, and can encrypt data using it, that only the owner, with access to the private key, can decrypt.
Anyone in the world can encrypt a message that only you can decrypt. That's the way it works. Alternatively, when you sign a statement, you're establishing that the owner of the key pair signed it, as only the owner has access to the private key. Then, anyone in the world can verify your signed statement using your public key.
You don't get to choose which one you use. In the example from my original post, the ssh-agent only needs reference to the location of one of the two keys, and will use the filename regardless, to distinguish between public and private. If I point the configuration option to this_is_my_key indicating a private key, it will automatically use this_is_my_key.pub as a public key. If I indicate this_is_my_key.pub then it does the reverse and will assume that this_is_my_key is the private key. It doesn't matter which one you specify, the ssh-agent just needs a filename to work with.
You're going to be very hard pressed in finding a VPN that supports torrenting. People abuse it. That's why mullvad pulled port forwarding support.
Additionally people misinterpret what they can do even if their VPN does support torrenting. It's still illegal to use their service to torrent anything other than legal torrents...which almost no one does, which is why VPN providers aren't lining up to show their support for the torrent network.
There are no services available to you that allow you indiscriminately to torrent illegal content. It's always illegal and against TOS to torrent someone elses IP.