reinar @ reinar @distress.digital

Posts

1

Comments

65

Joined

2 yr. ago

Turns out many middle eastern toilets can’t handle toilet paper.

It's more about toilet paper than plumbing. Toilet paper has to easily dissolve in water, otherwise you can clog any toilet, be it western or eastern.

yeah, in a few well-marketed cities you usually find on postcards. "Europe has great public transportation, I was in Munich last week...", right, because whole continent = one city.
In majority of the cities and countryside it's either get a car or get fucked.

10% is too low. Usually they won't be against paying you the same they are paying your current employer for your services, so you can safely do 20% raise ( your employer charges more, of course, but there are other costs involved to set up and run the operation).

with arch it's relatively easy given enough experience to build for someone absolutely minimal desktop environment which will run you a browser and that's it and it will be rock solid even with rolling release updates because there's nothing to break.

every time I've tried "out of the box" desktop experience of ubuntu and likes it's been atrocious with a lot of moving parts.

that's just because the USSR ruined them...

Germans still pay solidarity tax lil bro... USSR was one of the most talented entities in fucking up entire countries for decades to come, politburo was producing most vile, scheming and backstabbing ruling class ever to imagine. The very same people were running privatization and scraping all the social security programs in place, your boys from the West in Yeltsin's team were simply lacking and couldn't keep up.

yes, goes well together with Voyager. From app subdomain I route mobile clients to Voyager and desktop to Alexandrite, feels amazing.

database migrations will take a while for big instance, but other than that - smooth sailing.

communities

it's a band-aid, popular instances will be still under pressure to serve end users. Ok, they got the message through push from some other server instead of their user submitting it directly and the instance is not responsible for pushes to community subscribers (which is something, but not much, actually), however in the end it ends up stored locally and users still will be sending requests to popular instance to get their content if they are registered there.

users

not happening. It's a problem to change even username (and requires federation consensus first implementation-wise, it's not only lemmy around here), changing user's server will need fairly complex extension for id redirects or update propagation or something.
https://socialhub.activitypub.rocks/t/changeable-usernames/830
In general it's the same problem with migrating communities - you need to somehow update all the existing subscriptions across the federation.
I hope to be corrected on this, but this doesn't look too good.

I'm not shitting on lemmy and activitypub in general, it's a step in the right direction, however there are a lot of by-design issues which makes them prone to the very same problems as non-federated websites.

Lemmy is not truly distributed at this point, there are few well-known instances which are bearing the load and the rest is just sipping stuff through activitypub subscriptions.
If this thing will become even remotely popular with current architecture they have to follow the same path donations -> commercial or die. Serving a lot of users costs money, serving media content costs even more money. It's not a problem at the moment, but it will be.

ActivityPub is not a magic bullet, it's just a spec on how servers talk to each other. To truly involve each and every server in sharing the workload there's a need in something on top of that, or even better - replacing that since w/o active participation of client apps in load balancing it'll be the same reverse proxy shit in the end.

you need to set up port forwarding not only with your vpn provider, but also with gluetun:

https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/vpn-port-forwarding.md

good way to accidentally lose the data.

in case of any forensics your drive will be copied first and master will be not touched, any decryption attempts will be executed on copies - so kill switch is effectively useless.

there's a lot of different C's out there - I mean coding for microcontrollers looks really different to coding graphics with opengl, for example, especially for a beginner.
What do you want to do achieve with C specifically?

ramnode or linode will do, you'll need 2+GB of RAM.

C#

eh... those are fundamentally different, C is not object-oriented so OOD part goes straight out of the window. The only thing similar about them is syntax to some degree (which is really irrelevant), approach is completely different.

1000 daily visitors

it's not much, any non-micro vps from decent provider will do. For precise recommendations it'd be better to know where most of your users are located, latency is a bitch.

I've updated to 0.18.0 as well and can see your comment

It's not even about gui.
If you want to self host you get yourself a pile of software of community-level quality (i.e "it works good until it doesn't" is the best outcome) you need to care about. This means constantly being involved - updating, maintaining, learning something, etc, and honestly it's time-consuming even for experienced sysadmins.

Generated wireguard config with nat-pmp enabled in ProtonVPN panel, put keys and endpoints to my vpn client (gluetun docker image), used https://github.com/soxfor/qbittorrent-natmap image to interactively update port from qbittorrent settings on proton through natpmpc.

https://github.com/soxfor/qbittorrent-natmap/issues/13 - I've set up my docker-compose pretty much by this example (ignore "unreliability" feedback, OP probably has some issues upstream - image itself is working). If you are using this, remove all upnp/nat-pmp checkboxes from qbittorrent, this image is your nat-pmp client.

Speaking of clients: this setup is for sure extremely ugly, but native implementation of nat-pmp in libtorrent for some reason is not doing what's needed, maybe because qbittorrent tries to use upnp/nat-pmp simultaneously. What I see is an error message from upnp client ("no router found" - understandable) and complete silence from nat-pmp.

They are now refunding past their 30-day money back period if you didn't use cash. Just got a refund for a top-up made in February.

https://lemmy.dbzer0.com/post/21703
I ended up buying ProtonVPN. Port forwarding required a bit of trickery with natpmpc image to set up in my case (headless wireguard gateway for dockerized services), however now it's fine and working.

Speeds are at least 800Mbps download (which is maxing out my uplink, vpn is likely to be capable for more), didn't have a chance to test upload.