Max-P

When you subscribe to a community, you only start receiving data from that point on. It doesn’t go and download the history, that’d be very resource intensive on the remote instance. Thus it fetches a handful of posts, and no comments as a preview of the community, and after a couple days of activity is looks mostly normal.

The idea that GPT has a mind and wants to self-preserve is insane. It’s still just text prediction, and all the literature it’s trained on is written by humans with a sense of self preservation, of course it’ll show patterns of talking about self preservation.

It has no idea what self preservation is, even then it only knows it’s an AI because we told it it is. It doesn’t even run continuously anyway, it literally shuts down after every reply and its context fed back in for the next query.

I’m tired of this particular kind of AI clickbait, it needlessly scares people.

To kind of visually see it, I found this thread of some guy that took oscilloscope captures of the output of their UPS and they’re all pseudo-sines: https://forums.anandtech.com/threads/so-i-bought-an-oscilloscope.2413789/

As you can see, the power isn’t very smooth at all. It’s good enough for a lot of use cases and lower end power supplies, because they just shove that into a bridge rectifier and capacitors. Higher end power supplies have tighter margins, and are also more likely to have more safety features to protect the PC so they can get into protection mode and shut off. Because bad power can mean dips in power to the system which can cause calculation errors which is very undesirable especially in on a server. It probably also messes with power factor correction circuits, which is something cheap PSUs often cheap out on but a good high quality one would have and may shut down because of it.

As you can see in those images too, it spends a significant amount of time at 0V (no power, that’s at the middle of the screen) whereas the sine waves spends an infinitely short time at 0, it goes positive and then negative immediately. All the time spent at 0, you rely on big capacitors in the PSU to hold enough charge to make it to the next burst of power. With the sine wave they’d hold just long enough (we’re going down to 12V and 5V from 120/240V input, so the amount of time normally spent at or below ±12V is actually fairly short).

It’s technically the same average power, so most devices don’t really care. It really depends on the design of the particular unit, some can deal with some really bad power inputs and manage just fine and some will get damaged over long term use. Old linear ones with an AC transformer on the input in particular can be unhappy because of magnetic field saturation and other crazy inductor shenanigans.

Pure sine UPSes are better because they’re basically the same as what comes out of the wall outlet. Line interactive ones are even better because they’re ready to take over the moment power goes out and exactly at the same spot in the sine wave so the jitter isn’t quite as bad during the transition. Double conversion is the top tier because they always run off the battery, so there’s no interruption for the connected computer at all. Losing power just means the battery isn’t being charged/kept topped off from the wall anymore so it starts discharging.

If you look at my username you’ll see I do run my own instance so I’ve gone through the process :)

I would probably just skip the Lemmy Easy Deploy and just do a regular deployment so it doesn’t mess with your existing. Getting it running with just Docker is not that much harder and you just need to point your NGINX to it. Easy Deploy kind of assumes it’s got the whole machine for itself so it’ll try to bind on the same ports as your existing NGINX, so does the official Ansible as well.

You really just need a postgres instance, the backend, pictrs, the frontend and some NGINX glue to make it work. I recommend stealing the files from the official Ansible, as there’s a few gotchas in the NGINX config as the frontend and backend share the same host and one is just layered on top.

Hasn’t cost me a penny, hurray for unmetered bandwidth

To add: a lot of cert providers also offer ACME so while the primary user of ACME is LetsEncrypt, you can use the same tech and validations as LetsEncrypt on other vendors too.

What often happens next is the realization that the existing system was handling far more edge cases than it initially appears. You often discover these edge cases when the new system is deployed and someone complains about their use case breaking.

The reverse is also sometimes true and it’s when a rewrite is justifyable.

I’ve worked with many systems that piled up a ton of edge cases handling for things that are no longer possible, it makes the code way harder to follow than it should.

I’ve had successful rewrites that used 10x+ less the amount of code, for more features and significantly more reliable. And completely eliminated many of the edge cases by design.

IMO a lot of what makes nice self-hostable software is clean and sane software in general. A lot of stuff tend to end up trying to be too easy and you can’t scale up, or stuff so unbelievably complicated you can’t scale it down. Don’t make me install an email server and API keys to services needed by features I won’t even use.

I don’t particularly mind needing a database and Redis and the likes, but if you need MySQL and PostgreSQL and Redis and memcached and an ElasticSearch cluster and some of it is Go, some of it is Ruby and some of it is Java with a sprinkle of someone’s erlang phase, … no, just no, screw that.

What really sucks is when Docker is used as a bandaid to hide all that insanity under the guise of easy self-hosting. It works but it’s still a pain to maintain and debug, and it often uses way more resources than it really need. Well written software is flexible and sane.

My stuff at work runs equally fine locally in under a gig of RAM and barely any CPU at idle, and yet spans dozens of servers and microservices in production. That’s sane software.

There’s definitely security advantages to running things across multiple instances: if one gets hacked, the others are unaffected.

The networking should be pretty simple for what you’re doing. A few things just change to like 127.0.0.1 to something like 172.31.X.X or whatever IPs your VPC ends up using.

It looks like you’re doing very well, I’ve seen big companies with less security than that.

Misconfigured CORS is no worse than someone using curl, or postman, or any other tool of that kind. What could compromise your server is the backend side of things, the frontend is just a limited HTTP client in the end. The real risk is those making direct requests to your server. CORS is just an ask for browsers specifically to stop cross domain communication, it protects the users not you.

You can help that a lot by using containers like Docker or Podman, but you should also make sure your backend is secure. But the most risk really even then would usually be, break into your database via SQL injection or something like that, still not breaking into the whole instance.

If anything, making sure to use SSH keys, disable root login and general server best practices is way more important than your app. You’re more likely that your server itself will be attacked than the backend. Security comes in layers.

But realistically you’ll be fine, and if you do end up hacked, it’s a learning experience.

Legal content that violates community rules or instance rules but is otherwise harmless like spam, is kept in the modlog just fine. People don’t generally browse the modlogs as you generally can’t interact with the stuff anyway. No upvotes (more likely, tons of downvotes), no commenting. Not much better than going to the internet archive to undelete a post elsewhere.

More extreme content like CSAM usually gets deleted then purged instead, which is a feature that properly goes in and wipes the content permanently.

If you look at it from a different angle and ask: who might be interested by a user being reported, given that each instance operate independently? The answer is all of them.

• The instance you’re on could be interested because it might violate the local instance’s rules, and the admin might want to delete it even if from just that instance.
• The instance hosting the community, because regardless of the other two instances they might not want that there.
• The instance of the user being reported, because it’s their user and if they’re causing trouble they might want to ban the account.

The rest comes naturally: obviously if the account is banned at the source it’s effectively banned globally. If it’s banned on the community’s instance, then you won’t see that user there but might on other instances. And your instance can ban the user, in which case they’re freely posting on other instances but you won’t see it from your perspective.

But capacitors are so expensive, it’s like a whole 10¢ extra to filter it out so it doesn’t flicker!

I think it’s not as much as we expect everyone to host theirs themselves, but that it’s possible at all so multiple companies can compete without having to start from scratch.

Sure there will be hobbyists that do it, but already just on Lemmy users already have the freedom of going with lemmy.ml, lemmy.world, SJW, lemm.ee and plenty more.

It’s about spreading the risk and having alternatives to run to.

You just put both in the server_name line and you’re good to go.

Post the Hyprland config too?

Does it make the entire screen green by chance, not just the windows? If the shader applies to the whole screen, then setting alpha on it doesn’t really makes sense and is probably discarded since your monitor can’t display transparency. You need to make sure it applies on a per-window basis for them to be composited as transparent and show your wallpaper behind it.

You might be able to convince Firefox to be transparent with a GTK theme as Firefox uses GTK under the hood for the window. If you’re lucky it won’t bother clearing it with black just in case and it’ll actually be transparent.

The shader option is pretty neat and easy though.

With Docker, the internal network is just a bridge interface. The reason most firewall rules don’t apply is a combination of:

• Containers have their own namespace including network namespace, so each container have a blank iptables just for them.
• For container communication, that goes through the FORWARD table, not the INPUT/OUTPUT ones.
• Docker adds its own rules to ensure that this works as expected.

The only thing that should be affected by the host firewall is the proxy service Docker uses to listen on a port on the host and send it to the container.

When using Docker, each container acts like an independent machine, and your host gets configured to act as a router. You can firewall Docker containers, the rules just need to be in the right place to work.

Also, series F but they’re only deploying on one server? Try scaling that to a real deployment (200+ servers) with millions of requests going through and see how well that goes.

And also no way their process passes ISO/SOC 2/PCI certifications. CI/CD isn’t just “make do things”, it’s also the process, the logs, all the checks done, mandatory peer reviews. You can’t just deploy without the audit logs of who pushed what when and who approved it.