pitninja

To be clear, you’re not going to find many displays that can reach 4,000 nits yet. A lot of HDR content actually is mastered for 1,000 nits and that’s considered kind of the target for the mid-high range OLEDs right now. My pretty much top of the line QD-OLED Samsung S95C maxes out at something like 1350 nits. A 1000 nit capable Steam Deck OLED has plenty of range in luminance for HDR to be effective there. And I’m sure it’s got pretty good color reproduction which is the other big aspect of HDR.

One thing we haven’t talked about is the possibility that the Steam Deck is enhancing SDR content with dynamic tone mapping to such a degree that it’s difficult to tell the difference when you actually enable true HDR. I’d really have to see this with my own eyes to be able to say with more certainty what’s going on.

Yeah, the difference should be easily visible assuming one has quality source material and a nice display. I was kind of assuming OP was talking about using the Steam Deck in docked mode, but maybe that was a bad assumption.

deleted by creator

Thank you for laying it all out there. It sounds like you’re doing it the right way 🙂

Thank you for providing some context for this. It kind of sounds like a fork might not have been necessary if Ernest was willing to make @melroy a maintainer. Do you know if there’s any philosophical reason he wasn’t willing to do that? Real life stuff comes and goes, but it seems silly to halt the “official” project that others are relying on and still wanting to improve upon and thereby force a fork. As it stands right now, it sounds like it will be awkward for Ernest to come back in and try to restart work on kbin and will be increasingly awkward the more that mbin progresses, becomes the standard, and the code bases diverge.

It’s kind of interesting to watch in open source which projects survive and which get forked and essentially made irrelevant. It basically becomes a referendum on the vision of the original individual or team and how well they’re serving the collective user base. If they aren’t accepting PR’s and competently managing development, they’ll likely be forked. So I’m glad to see that folks are making progress with mbin and I can’t help thinking that its entire existence is probably due to individuals not being able to agree on a roadmap for the platform. If anybody has any info on any drama that led to this, I’d be curious to read about it.

What you’re describing is only possible on de-anonymized platforms that essentially have “know your customer” type policies where users have to provide some kind of proof of their identity. While I agree that there is value in social spaces where everyone generally knows the people they’re interacting with are who they say they are, I don’t think this is ever going to be feasible in a federated social platform. I think Facebook is the closest thing we have to what you’re describing, to be honest, and I believe Meta has even kicked around having a more sandboxed Instagram for minors (though I don’t use Instagram, so I’m not certain on the details there).

For me, in most cases on a platform like Lemmy, a person’s age is not something I care about. I care about what people are sharing and saying. But then again, none of my interests for online discussion at this point in my life are really age centric. I think there are clearly better platforms than Lemmy if people want to guarantee they’re only interacting within their age specific peer groups.

I stopped paying for YouTube the moment Google killed Google Play Music and forced YouTube Music on me. Now Google gets no money from me and Apple does because they still offer a true music library service.

I was able to get video streaming with audio working on Discord using pipewire, but it was a massive pain in the ass and somewhat unreliable. I don’t have a lot of experience with Jitsi, but I trust others’ recommendation there

If you want to learn a little bit more about Lemmy, this docs page on join-lemmy.org is a pretty good primer.

Calibre is a fantastic and underrated tool.

No worries! The Fediverse is a different world with unfamiliar terminology and we’ve all been there.

I think maybe you are confusing instances with communities? Instances are the servers you sign up your account on like lemmy.world or lemmy.ml whereas communities like asklemmy are hosted on an instance. I think there’s universal agreement that growing communities is generally a good thing because it leads to more content and discussion. Growing instances on the other hand isn’t super important (indeed there are going to be plenty of people like myself that are going to stick with a single user personal instance and be perfectly happy). I think the person you’re replying to was confused by the wording of your post.

Why not? Plasma is much more usable out of the box for many users including myself. GNOME’s out of the box experience is really lacking IMHO and requires me to install and configure several extensions just to get what I consider to be a functional UI. I know they have this vision for how they want people to use their OS, but that vision is not aligned with how I actually want to use it. The best way distros can vote against the design choices of GNOME is by making something else the default. The problem I have is that I generally prefer GNOME’s app suite to KDE’s, so that makes the decision a bit more complicated for me.

Believe it or not, we’re living in the most peaceful period of human history thus far. I’d recommend the book The Better Angels of Our Nature by Steven Pinker which talks about how far we’ve come. That said, I see the threat of global warming, lack of fresh water, famine, and energy scarcity becoming threats to the current status quo, though. If we don’t figure some things out as a species, we’re likely in for some turbulent times in the next hundred years.

Personally, I think it’d be nice if you could self-host just the bridge instances and connect them with beeper yourself, so that the part that isn’t e2e encrypted is running on software you can validate and hardware you control.

I 100% agree this would be a great solution. That’s what I thought this page was going to be at first until I kept reading and realized it’s just a config guide for the Matrix Ansible setup. I wish they didn’t say “self host Beeper” on that page at all because self hosting Matrix has absolutely nothing to do with the Beeper service other than their devs built the bridges that they’re showing you how to set up with Matrix.

It’s almost not even fair to say they’re merely contributing back to the upstream bridges. Most of the bridges would not exist at all without the Beeper developers.

It’s also kind of funny that the section of their website you quoted still has language that implies you have to pay for Beeper when it’s been free for months at this point. The primary reason to self host Matrix at this point is for privacy and complete control. And self hosting Matrix is only free if you use existing hardware and I would recommend a cloud instance for most people.

Beeper’s server set up is actually a lot more complicated than just standard Synapse at this point. When they say you can “self host Beeper” that’s really not accurate at this point at all. All of their 3rd party chat bridges are dynamically spun up on a per user basis with hungryserv and those servers operate in parallel with a synapse server for Matrix interoperability all behind a roomserv server. Here’s a presentation that one of their lead developers created regarding their new architecture.

Afaik, that isn’t in effect yet, but will become a major factor next year.

E2EE only exists up to the bridge, not the whole way to your client

I just want to clarify that most bridges can be set up to have E2EE between the Matrix client and the bridge (regardless of whether the bridge supports encrypted chats on the bridged service because not all do, e.g. Facebook), but it is true that the bridge itself has to decrypt and translate between Matrix and the 3rd party chat service, so as you mentioned trusting who hosts bridges or doing it yourself is really important.