Gul is a rank IIRC and Dukat is a villain, haha
sparky
joined 2 years ago
MODERATOR OF
Der Spülautomat, Der Tellerwäscher, Die Abwäscherin… wait, no
Native German speaker here but I also speak Spanish, Portuguese, French and Swedish. Each of these languages handles them differently so I am thinking there’s not a general answer here.
It also can depend within each language on some context. For example in German many neologisms are automatically neuter (das) unless they happen to resemble some common pattern. For example a lot of German words that end with an -e are feminine and sometimes that is applied to neologisms too.
Native German speaker here, can confirm yes, there are some patterns but mostly the genders are pretty random; but a Waschmaschine is feminine because a Maschine is feminine, yes
Some do, but what Google rolled out in Android Messages is their own implementation unrelated to the carriers. Ostensibly so it works regardless of carrier, but what they rolled out is a semi-proprietary implementation that only works on their app. Ergo if you use a third party texting app, no RCS. So it’s a sort of “Android iMsssage” thing anyway. Apple plans to implement Google’s version, again sidestepping the carriers.
Nothing doesn’t have anything real - it’s a Mac in the cloud with some janky scripting puppeting Messages.app. They haven’t figured out how to plug in at a protocol level or anything.
iMessage is a rich communication layer backed by HTTPS and web sockets so think something like WhatsApp or Telegram; you can send 2 gig files, embed maps and other rich content, etc etc. SMS is well… SMS. So the blue versus green bubble is a dumb reductionist view but the practical impact is visible in say video messaging, where an iMessage can attach a 50mb 4K H.265 clip same as a real messaging app, whereas an MMS will be a 256k 3gpp potato.
In theory anyone can host an RCS endpoint but in practice that means carriers (historically) or OS vendors (in modernity). So in effect yes all RCS messages will pass through Google servers, but mostly because Apple to Apple texts will remain on iMessage. But any texts starting or ending on Android will go through Google. Note that this doesn’t really change much as Google’s privacy policy for Android users already discloses the bulk ingestion, scanning and processing of communications, including text messages.
Former Google and current Apple engineer here; this is definitely an insecure workaround with a lot of flaws. I think Beeper is basically doing the same.
The reality is that while we do have a lot of walled garden policies for business reasons (which I don’t love), iMessage and FaceTime are a bit more complicated than that, tightly coupled around the hardware encryption and keystore in the TPM in our devices. Unwinding this would be undesirable from a compatibility perspective as it would break any Apple devices not updated immediately to new OS versions that change the encryption scheme.
So the only way to plug into iMessage per se is a weird workaround like this where you basically AppleScript automate the Messages app on a Mac with its shields down.
There’s not a great way to fix this problem which is largely why we are bringing RCS support to iOS 18 to hopefully make such things moot.
But that said even as an employee I don’t think iMessage is a great example of a modern chat app. I mean, it’s better than SMS which is what it sought out to replace. But compared to an actual chat app - something like Telegram - it doesn’t hold up.
Im Kontext von Feddit.de ist es mehr ein Kilometerstein, oder? (Sorry)
I think it’s kind of a slippery slope; but I don’t think the search itself being login walled is apocalyptic. As long as anonymous users can clone the repositories and browse the code, I can kind of understand why they don’t want to pay to run an elastic search cluster for bots’ benefit. Presumably in-repo search could be done locally by scrapers’ hardware.
But if it turns into “login to view this repository” then GitHub will have turned evil.