Thanks to OpenMW, my SteamDeck has become a "Morrowind machine" -- it runs so well and it's so convenient to have all that world with me on the go. You can use https://luxtorpeda.gitlab.io which registers as one of the runtimes Steam uses to launch games -- Proton being one of them -- and behind the scenes Luxtorpeda will download and run OpenMW instead of Morrowind.exe.
question, do you use the Linux native version of OpenMW or the Windows native version via Proton?
Anecdotally i've heard some of the windows/proton versions of games have better performance than linux natives of the same game?
So theres this weird situation now where some windows native versions of games run better on linux than on windows and also run better than the linux native versions lol.
It seems like a wasted opportunity to set up a new domain (in this case: wikimedia.social) rather than use an existing one with a subdomain, e.g. social.wikimedia.org or social.wikimediafoundation.org. With a new domain I still have to do the work to verify whether the domain is indeed owned by the Wikimedia Foundation.
There's some background at https://phabricator.wikimedia.org/T337586 - a wikimedia.org subdomain was out of the question due to security concerns (it'd involve giving a third party a SSL certificate for wikimedia.org) [1], and wikimediafoundation.org was ruled out because it could cause confusion about volunteers' relationship to the Foundation [2]
From your first link, it seems the decision to use a different new domain stems from difficulties getting the server's HSTS policy right, and it even seems they had a similar issue in the past with having the store as a subdomain [1].
If that's true, for a use case as functionally basic as having a store and a social instance in their respective subdomains, it looks to me like a complete failure of HSTS, a case of technology causing problems that shouldn't exist to begin with.
It's not linked there (or on any Wikitech pages I can find), but I can imagine there's a secondary concern of *.wikimedia.org cookies getting sent to third parties - e.g. Stack Overflow has separate second-level domains (stackoverflow.email/stackoverflow.blog) for their 3rd-party-hosted email service and blog for exactly this reason (cf. https://nickcraver.com/blog/2017/05/22/https-on-stack-overfl...)
Seems the real issue is that Mastodon is too hard to self host if not even Wikimedia wants to do it.
> it'd involve giving a third party a SSL certificate for wikimedia.org
You can have certificates for subdomains. With Let's Encrypt you still need to control the root domain to generate them so they'd have to setup something for that. But that's more a can't-be-bothered concern than an actual security concern. Teaching the public to trust random domains being authentic is a much much bigger security concern anyway.
I think it'd be great if there was a way to push the identity through a different domain. @foundation@mediawiki.org or such. Needing subdomains is so clunky - imagine if you were example@mail.gmail.com, yuck.
We can get half way there with /.well-known/webfinger - but the alias that provides doesn't show up in the feed, so that's not the username I find from links like OP's.
It can accrue reputation the same way Wikipedia.org did while providing a spot to add other things like PeerTube without worrying about the security peculiarities that led to them choosing this route in the first place.
> - # private... not sure why they didn't just use the "private" keyword, but I don't care. I almost always use TypeScript anyways
One of the reasons was to allow private and public fields of the same name, so that subclasses are free to add own public fields without accidentally discovering private fields of superclasses. There were many more considerations that went into the design: https://github.com/tc39/proposal-class-fields/blob/main/PRIV....
If I had to venture to guess based on how their APIs work, it's probably events. There's a system called "NotificationCenter" which can be observed to receive system events within Apple API's which is quite old.
Cocoa also lets you two-way bind a state object with the view as long as the state object (whether it's a controller or a model or a view model) implements key-value coding; notably, the blessed data framework (Core Data) is KVC-compliant, so apps that use Core Data sort of get all this for free. Core Data also has fairly good support for undo/redo. That being said, Core Data is a fairly idiosyncratic relational data layer. It's sort of a double-edged sword: it's easy to do 90% of what you want, and the last 10% will involve some deep dives into Apple's documentation. But it's been a long time since I've written an app on OS X -- someone will have to correct my errors.
I've long thought that the inverse of what the OP suggests, bringing reactive UI programming techniques to Cocoa, would be much more interesting. Making native apps just as easy and as fun to build as web apps would be great! ReactiveCocoa/ReactiveSwift are promising, but the underlying, mutation-heavy Apple APIs still peek through. SwiftUI also seems promising, but still relatively immature to the, gosh, decades-old OS X platform.
Tangentially related: https://js13kgames.com is currently going on -- the challenge is to build an HTML/CSS/JS game which compresses down to 13,312 bytes or less.
If it's something I want to read and then be done with it, I keep the tab open.
If it's something I may want to come back to, or something that I'd be sad if it disappeared from the web, I save it to a synced folder using the SingleFile extension which inlines all content into a single HTML file.
Type inference is one good reason. Similar syntax exists in a few modern languages, too: e.g. Rust and Swift. In languages with type inference it can be convenient that type annotations are in the postfix position relative to variable names:
let user = new User();
let user: User = new User();
> The second option shouldn't need to match as it is the default value anyway (signified by the *)
That's an interesting suggestion! Right now, the identifier between the brackets is required, but we could relax this in the future. In 1.0, we erred on the side of more conservative and explicit design, to improve the readability and discoverability of the syntax for translators.
The (2..4) range would work for Czech in this example (if I'm reading the CLDR right), but I'm afraid it wouldn't be sufficient for languages with more complex plural rules. Take the rule that returns "one" in Latvian, for example:
n % 10 = 1 and
n % 100 != 11 or
v = 2 and
f % 10 = 1 and
f % 100 != 11 or
v != 2 and
f % 10 = 1
…where n is the absolute value of the number, f is the visible fractional digits with trailing zeros, and v is _the number_ of visible fraction digits with trailing zeros. Some rules can get even more complex than that; see [0] and [1].
It's safer and more robust to rely on the plural categories defined by the Unicode: (zero | one | two | few | many | other), and by the APIs provided by the platform (ICU, Intl.PluralRules, etc.).
You can get decent highlighting for basic Fluent messages by setting the editor to a mode for Properties files. For instance, whenever I type Fluent examples in GitHub, I use the following markdown:
```properties
# A comment
hello = Hello, world!
```
This is in fact by design. Properties files are quite nice for simple things. Fluent builds on top of them, and provides modern features like multiline text blocks (as long as it's indented, it's considered text continuation) and the micro-syntax for expressions: {$var}, {$var -> ...} etc.
So far, I haven't had much time to invest in building proper highlighting modes for popular editors. There are ACE and Vim modes mentioned in other comments here, and also a slightly outdated https://atom.io/packages/language-ftl20n written by a contributor. I'd love to see more such contributions, and I'll be more than happy to help by reviewing code!
