I don’t care for the argument one way or another; I’m not an EU resident and the whole thing is irrelevant to me as an individual.
I’m merely pointing out neither the Fediverse/Lemmy/etc. nor Reddit as a platform cares for EU’s privacy concerns, and people should be well informed when entering either platforms, so they’re not doing so with the false sense of security that they’d be able to exercise those government granted rights effectively.
Good luck with that. Once the post federates out, the host instance can request for deletion, but any federated instances that receives the content doesn’t necessarily have to follow that request. They could easily modify their instance to not delete, they may reactivate the content from moderation log, they might have backup strategies that involves retaining data (for their own local legal reasons), etc etc.
It’s probably best to assume any content that you post on Lemmy are out of your control and will live for much longer than you’d expect.
This is not limited to just Lemmy but any federated systems. So regardless centralized corporation behind the service, or an open federated system; one way or another, whatever you post out there, its no longer yours to control.
One potential downside to this on the posts/comment front is that if the thread in question is not in a community your instance is federated with, any form of local redirect would yield just an empty post with no comments. Lenny’s current federation is primarily push driven, so when requesting a post from an unknown community will yield no historical comments, as your instance have never subscribed to the community and thus never received the push notifications. Whereas getting sent to the original instance, you’d be able to see the full interaction history and have a better picture of the intended discussion.
In the future, please use cross post instead and not click bait titles into different communities.
On a more related note, do you have knowledge if the image was federated outwards? I’m fairly sure I’ve subscribed to that community, so there may be an off chance I have received a copy of the image as part of federation. Is there any way to scour other instances to find images that is federated out and needs to be removed?
I skimmed through that yesterday and didn’t see any mentioning of a buffer overflow. I’ll have to check that again later when I can sit down to look at my laptop.
Do you have a source that you could share on this?
“Too complicated” feels like a cop out… there’s no question as to whether or not clients can send both, from best practice point of view, the party instilling the change should bore the burden of supporting both for some time. I cannot and do not want to change the current release train, but I hope you can take this into consideration into the future, for future breaking changes.
I’m not asking about whether or not clients can do it, there’s no doubt a dual outbound header method is possible, but rather more about general development best practices. When instilling a change, isn’t it usually best to support both states to ensure least amount of users are immediately affected, and gradually bleed those stragglers out?
With the authentication header update, isn’t usual best practice to support both on the server side simultaneously, and set a deprecation window such that clients can update over time?
That’s what I missed during my setup. I’m currently stuck without the LVM layer. With LVM, I think you can also theoretically add lvmcache and throw SSDs in front of your RAID array to act as cache, thereby improving the performance of your array. That’s another thing worth considering if you’re just setting up now.
You’re missing the point. For most residential deployments, which appears to be the use case here in this thread, it is not viable to expect deployments pre configured with the intended final/stable quantity of drives. Say someone deploys 6 drives today, a sizeable commitment for most residential deployments, for a RAIDZ2 deployment, they cannot later down the line add 2 more, and then 2 more without affecting the overall redundancy (data on the new 2/2 drives will either have no redundancy or 1:1 redundancy in their own vdevs). Lets also not pretend everyone will easily have a spare cluster sitting around to house all current data while they’re rebuilding the cluster for expansion. This inability to linearly expand as compared to more conventional md raid (or even hardware raid assuming if you have enough ports), where the lowest denomination in expansion is 1 drive at a time, any given time, basically eliminates it as a suitable candidate for most residential usage, as vast majority of residential users will not be expanding their raid in quantities of 6, 8, or 10 drives — and even if they do, vast majority wouldn’t want to take the extra hit on “sacrificing” more drives to parity. All that are things that are perfectly normal and expected in the enterprise space, but not residential.
And yes, the article I’ve linked has multiple updates which covers what is happening now. It’s not a stagnant outdated article. I’m well aware they’re intending to merge the vdev expansion PR, sometime this year, for the last I don’t even know how many years. I’ll re-evaluate ZFS when it is merged and appropriately battle tested in the wild.
I have 8x 8TB in a RAID 6 setup via vanilla md raid in an over provisioned server. Works well enough for me and my family’s needs. You’ll likely hear a lot of proponents for ZFS, and yes there’s no doubt it is more modern with some great features, but unless you’ve got your entire setup planned out, watch out for the hidden cost of zfs.
I don’t understand (in this day and age) how any of these protocols have comparable performance difference to need the “Fast”/“Slow” row. None of these protocols would be computationally intensive enough to make a difference in performance, and should be only limited by line speed, no?
Just say your cybersecurity insurance will not cover damages caused as result of inclusion of applications that are not compliant with the policy, loop in legal, sit back and watch how quickly bricks are shat.
If you want to know how they’re built, look for Dockerfile in the code base; that’s usually the file that would create a container image when docker build … command is used. Perhaps you’d also see something about CI and you’d find a build server some where, too.
Works very well on vanilla docker compose as well. Annotate containers with labels and it will wire itself up automagically. It’s wonderful.