wpuckering
- 0 Posts
- 14 Comments
Yeah that’s probably the strongest point in favour of letting people pick what they want. But I guess a potential downside of that could be if people start stocking up mostly on only a few select items that everyone else also wants., leaving nothing behind for them. But I guess that’s mitigated by seeing that happen a few times then specifically trying to get even more of those select items going forward.
Yeah that’s a good point. If you can’t see what people are leaving behind, you can’t know what to stop taking more of. I guess you need to generate some short-term waste in order to properly tune things as needed, to hopefully reach a point where you’re reducing waste as much as possible in the longer term.
I wonder if letting people pick their own items really reduces waste more than the hamper system? What happens to items left on the shelf that no one takes? That’s probably the same stuff that would be ignored from a hamper? I’m admittedly pretty ignorant of food banks generally, but I would think that the hamper system would be trying to encourage people to eat whatever they get, to both reduce waste by making sure all items get out there from the bank, and to ensure there’s enough of everything coming in to go around evenly? I can see this maybe resulting in the better items going first, and a bunch of less desirable items always being left behind to rot. Does that tend to happen in this type of system or not?
Oh yeah for sure. It’s just a matter of time. Out of all of these options, some will just fade away (some already have within weeks of initial release), and some will remain and just continue to get better as the development community continues to get a better picture of where all of the action is, and starts to want to be a part of it.
You’re seeing that toast about versions since backend version 0.18.0 switched away from using a websockets-based API to a REST API, and the Jerboa client app is (in a not-so-descriptive way) warning you that the backend you are connected to isn’t aligned with the app version in terms of what it expects of the backed. This should go away pretty soon as more servers update their backend version and the Jerboa app update hits more devices.
It’s awesome to see Lemmy getting lots of love, and choice in the mobile app space is great for everyone. But some part of me also kind of wishes that rather than spreading so much development effort out over so many mobile apps, that more developers would jump in and contribute to polishing up the official open source Lemmy mobile app, Jerboa. I can’t help but feel that it would be nice to see a focused effort somewhere in bringing that one in particular up to snuff, as a sort of “reference” app. And have a few others floating around out there just for some diversity and testing innovative ideas.
Maybe it’s already that way, I don’t know.
However, that’s come with other tradeoffs in useability, speed, and fediration experience.
Like what? If properly configured none of the things listed should negatively impact hosting a Lemmy instance.
sure I’ll be adding an exception/rule for that, but it’s not a straight forward task.
It honestly should be to someone who would be hosting any public web application using Cloudflare. Cloudflare makes all of this quite easy, even to those with less experience.
Heck, the removal of websockets will require quite a few changes in my Cloudflare config.
What config are you referring to? In the Cloudflare console? For websockets changing to a REST API implementation there should be nothing at all you need to do.
Sure, someone truly concerned with security knows to do this, but that’s definitely not going to be everyone
And it shouldn’t have to be everyone, only those who take on the responsibility of hosting a public web application such as a Lemmy instance.
No matter the capabilities inherent in what you choose to host, the onus rests on the owner of the infrastructure to secure it.
Everyone should be free to host anything they want at whatever level of security (even none) if that’s what they want to do. But it’s not reasonable nor appropriate to expect it to be done for you by way of application code. It’s great if security is baked in, that’s wonderful. But it doesn’t replace other mitigations that according to best practices should rightfully be in place and configured in the surrounding infrastructure.
In the case of the captcha issue we’re discussing here, there’s more than enough appropriate, free solutions that you can use to cover yourself.
There’s nothing stopping instance owners from incorporating their own security measures into their infrastructure as they see fit, such as a reverse proxy with a modern web application firewall, solutions such as Cloudflare and the free captcha capabilities they offer, or a combination of those and/or various other protective measures. If you’re hosting your own Lemmy instance and exposing it to the public, and you don’t understand what would be involved in the above examples or have no idea where to start, then you probably shouldn’t be hosting a public Lemmy instance in the first place.
It’s generally not a good idea to rely primarily on security to be baked into application code and call it a day. I’m not up to date on this news and all of the nuances yet, I’ll look into it after I’ve posted this, but what I said above holds true regardless.
The responsibility of security of any publicly hosted web application or service rests squarely on the owner of the instance. It’s up to you to secure your infrastructure, and there are very good and accepted best practice ways of doing that outside of application code. Something like losing baked in captcha in a web application should come as no big deal to those who have the appropriate level of knowledge to responsibly host their instance.
From what this seems to be about, it seems like a non-issue, unless you’re someone who is relying on baked in security to cover for your lack of expertise in properly securing your instance and mitigating exploitation by bots yourself.
I’m not trying to demean anyone or sound holier than thou, but honestly, please don’t rely on the devs for all of your security needs. There are ways to keep your instance secure that doesn’t require their involvement, and that are best practice anyways. Please seek to educate yourself if this applies to you, and shore up the security of your own instances by way of the surrounding infrastructure.
I’m just really glad when I went through high school none of this was a thing. You worked hard and earned success, or you slacked off and suffered the consequences. Or you fell somewhere in-between as appropriate.
Our society has made it taboo to tell students the (sometimes) hard truth about where they stand, so that they can be aware of what they need to work on to improve. This fear of hurting feelings and this need to make everyone feel like a winner has stifled the drive and motivation that could manifest from the want to do better and prove yourself.
Deciding to work hard is, has been, and will always be a personal choice, but instead of encouraging that, we’re just trying to make everyone feel happy about themselves the way they are. That’s good for people’s mental health, but it’s harmful for long-term success. Those that would never put in the work in any case, never will. So at least create an environment where those that would can thrive. That’s what I think anyway.
I think the benefit of knowing the names publicly might be the public’s ability to then no longer elect these people, which cuts off the foreign interference at the root, as far as can be done within the country. It might also act as a deterrent for future MPs knowing their names could be released if they too partake in this behavior. It would accomplish stamping out the problem and publicly shaming these people for the rest of their careers.
Not saying it’s realistically feasible or prudent overall to actually release them though.