You can use it with code you can't modify (decorators are just convenience helpers, you can do same through bindings DSL with bit less type safety).
TSyringe depends on reflect-metadata and, if my understanding is correct, forces you to use its decorators.
The comparison table is completely subjective and made with just several glances at the readmes of the mentioned libraries. The point was to showcase phased DI for Typescript.
Even though I am for the eID I do share your worry but I don‘t think it‘s hopeless. Both politically and socially there are avenues to combat such over-identification. Still, most uses will probably more private than sharing copies of your ID so I am not sure what the gain for companies will be as it might just limit the customer base without much data gained. That does not seem in the interest of those companies. It‘s easier for the government to enforce certain checks, which is also not ideal but still there are avenues to fight this if it happens.
Afaik they respect robots.txt on crawl and later when using the data they re-check the robots.txt and will exclude the data if the new robots.txt was updated to deny access. They have further data filtering bit for that you better check the technical report.
I just got the iPhone 14 Pro version of it two days ago.
I like the texture very much and all-in-all it seems like a great case. The textured buttons and the wide island are very nice touches :)
The way I hold the phone in my right hand does make the connector-corner dig into my palm, which is not very comfortable. I'll see how well I can adapt.
Also the top piece has veeery slight warping which makes some seams not as seamless but does not impact functionality. I know it's a hand-made product so that's fine to me, just a reality check on what to expect.
The clasp of the top piece also seems a bit flimsy and even with the adjustments mentioned in the video I worry if it will break at some point.
The title is a bit misleading, Apple did not reject the submission, just not approved it (yet). I know ignoring a submission is practically the same as blocking or rejecting it; but I think this case is already messy enough so that these things should be read with more nuance.
Also the situation is much more complicated. In the EU, Fortnite has been available for a while through their own Epic Games AppStore. This submission seems to have been for both, the EU distribution and the US AppStore. I am surprised that such a situation is even possible, I thought if you opt-in your app/account for EU alternative AppStores you are kind of blocked from the standard AppStore submission as the requirements for the alternative distribution path are different from the AppStore. At the same time it seems to give Epic more arguments for pressure on Apple as sabotaging the release in the EU might be against the DMA laws.
Maybe you are right. „blocked“ still is a strange term to use when normally people speak of „rejected“ so maybe they just told them they won‘t approve it. The latest news is that they were told to resubmit for EU only and that will get approved.
Why do all articles say "with 784 GB of unified memory" for the Station when on the official spec page it's not listed as unified but as "GPU Memory: Up to 288GB HBM3e | 8 TB/s" and "CPU Memory: Up to 496GB LPDDR5X | Up to 396 GB/s"?
"Look, big organisations: if you try to freeride on FOSS your projects will fail" - I always understood "freeriding on FOSS" to mean reselling/repackaging without contribution to the project. But using "freeride" in the context of a company using a freely available FOSS tool by themselves ("org decides to do the project in-house") sounds strange to me. If the license allows me to use it why blame and shame orgs and people for using it?
So there is the Synapse version that is required to get the big money contracts and the Synapse that is pretty inconsequential to the business except as a testing playground. - Makes it difficult to see how "Element is fully committed to community Synapse" can be true in the long run. Does this not spread the development effort & focus even thinner across these projects? And would reduced memory & cpu requirements not benefit all deployment sizes and not just nation-scale ones? It feels very much as a pivot towards a closed stack.
It looks like i've done a bad job at explaining this, so i'll try to clarify:
Making worker processes go fast has most benefit to enormous deployments, as they won't run out of headroom when running lots of single-core python workers.
However, ALL deployment sizes benefit from algorithmic improvements to the protocol and its implementation - which are the cause of smaller servers being slower today.
Specifically:
* Merge conflict resolution (State resolution) is worse than O(N) complexity with the amount of state to be merged.
* All Matrix traffic currently runs full-mesh - there's no concept of "thin nodes" or delegating fan-out to a larger server.
So, fixing these issues is all going into open source Synapse (and Matrix as a whole) - which should unrecognisably improve performance, whether servers are written in Python or Rust or Elixir or whatever. And the hope is that $ from Synapse Pro funds that work (assuming the gambit is successful).
Meanwhile, all features, security work, perf optimisations (apart from scalability work), experimental MSCs etc will continue to land in FOSS Synapse for the forseeable.
After re-reading and reading many other comments in various posts I think I have misunderstood it partly.
So the workers part has been overhauled in Rust for Synapse Pro. Is this a complete re-implementation of Synapse so the big deployments with Synapse Pro will not run anything from the normal Synapse or is this only part of the whole stack and the Pro deployments will also run most of the normal Synapse?
But it seems like this move incentivizes you to not improve the open source server, at least such that the open source server is always inferior to the pro version.
If someone makes a new, more performant, open-source server, and it touches your bottom line then you're strongly motivated to "embrace, extend, extinguish".
The thing is, we've all heard this before, and it always ends up the same. I hope you prove me wrong, but I wouldn't bet on it.
> But it seems like this move incentivizes you to not improve the open source server, at least such that the open source server is always inferior to the pro version.
The idea is that we absolutely improve FOSS synapse in all ways - other than supporting enormous deployments. For instance we continue to land perf improvements to FOSS synapse and make average sized servers as snappy as conceivably possible. And all features land in FOSS synapse, etc. If we don’t it would harm the public Matrix network and we obviously don’t want that.
> If someone makes a new, more performant, open-source server, and it touches your bottom line then you're strongly motivated to "embrace, extend, extinguish".
Rather than EEE, I’d expect us to simply compete with that server - adding more features, better perf, better commercial support, etc. For Matrix’s sake, I hope that we end up in that situation tbh.
> The thing is, we've all heard this before, and it always ends up the same. I hope you prove me wrong, but I wouldn't bet on it.
I think the difference is that typically folks doing this are being greedy to grow a profitable (or could-be-profitable) company as aggressively as possible. Whereas here the motive is simply to pay for our FOSS dev and get to breakeven and be able to sustainably grow Matrix for the benefit of the whole network. If in the end a bit of proprietary software is the necessary evil to get there, sobeit.
Of course this could change in future, eg if mgt changed, but that’s true of anything. But the intention is categorically not to EEE (and on the Matrix Foundation side, the governance and spec process is set up to stop Element from being able to EEE even if it wanted to).
There is also the manga "As the Gods Will" which is not only a similar concept but has the exact same first game. Strange that this is never mentioned as an influence.
