stu

I assume you're not using iMessage anyway then because Apple's Messages stack isn't open source. If you're not using iMessage anyway, it shouldn't matter to you what Beeper Mini is doing. This app isn't for the ultra paranoid. Neither is Google's RCS in Google Messages. This is where Signal and Matrix would be better choices. If you are using iMessage on an Apple device, you're choosing to trust Apple despite their app being closed source and you're not choosing to trust Beeper, which is fine and I don't judge you at all for that stance. But at that point, your qualms aren't simply about Beeper Mini being closed source, the implication is that you don't trust Beeper as a company and/or its developers which, again, is a valid stance even if it's one I don't share.

But I am personally pretty sure I can trust Beeper and Apple enough with my relatively meaningless conversations.

I think you got hit hard by Poe's Law here. Except it's more like people couldn't tell if you were jokingly or genuinely getting your math wrong... Even after you explained you were joking lol

I would encourage people to code switch rather than adhere to one style of language over another in every case. Imho, it's kind of problematic that language itself has become racialized in America to the point where people can actually be criticized or made fun of for speaking in the "wrong" style associated with their perceived ethnic background.

I think they're great for giving OEMs extra incentive to ensure that Linux runs well on the hardware and providing consumers a slightly cheaper option. If I knew I wasn't going to need Windows at all, I'd definitely go the Ubuntu route, but there's software I use that doesn't run on WINE, so I'd personally be more inclined to get a laptop with a Windows license bundled in.

By that logic, there's nothing guaranteeing iMessage on iPhones is secure or private either because it's closed source. If you don't want to trust Beeper mini, you'll be free to run their iMessage bridge on your own Matrix stack when they open source it at some point, which they're promising to do (and you still won't know that Apple isn't scraping your messages on the iOS side). When I decide to trust a company, it's because I look at what they're transparently communicating to their end users. Every indication is that they are trying to get out of the middle of handling encrypted messages. Their first move to make this happen was allowing people to self host their own Beeper bridges (which you can still do with Beeper Cloud if you prefer and you will know that your messages are always encrypted within the Beeper infrastructure). They aren't going to release the source for their client ever because that's the only way they make any money.

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.

The federal government should charge Texas for the costs to remove the unauthorized barriers. The fact that the rest of us are paying for their idiocy is appalling.

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.