The NES' own sound chip didn't have a sawtooth channel, but some games had an onboard sound chip that added one, like Konami's VRC6: https://www.nesdev.org/wiki/VRC6_audio
Does Japan have those values, though? Last I heard, Japanese mostly don't travel (not abroad at least); strongly promote monogomy / long-term relationships; abhor the notion of adult children living with their parents; mostly don't have trouble deciding on which city to live in; and still put a lot of pressure for mothers to stay at home instead of going to work.
I should read TFA first but it seems like the root of their birth problem is simply that the financial & social costs of having children far outweigh the (short-term) benefits.
“There is, however, more evidence for a health risk from eating too few vegetables. That is really the risk of a high-meat diet, those meat calories are displacing vegetable calories.”
Isn't a calorie just a calorie though? Or is this in regards to what comes alongside those calories?
Honest question: why did TypeScript succeed while ActionScript 3.0, another ECMAScript-superset language with typing and OOP (and predates TS by a few years), is all but a distant memory? Is it more than just Adobe being a terrible steward of its tech?
With that said, TS is definitely a blessing; I recently had the privilege of migrating to it after having written a hobby project in plain JS, and the difference in usability between the two is night and day. But I can't help but feel that I've seen this all before years ago in AS3.
Self-hosted Matrix servers still incur the risk of leaking metadata to whatever other servers it federates with (which of course isn't a problem if you don't federate, but that kind of defeats the purpose of using Matrix in the first place).
IMO that's an acceptable tradeoff for achieving decentralization without making the protocol overly complex (AIUI something like Signal's "sealed sender" system doesn't work in a decentralized environment)...but it still feels like a nagging threat that needs a proper solution eventually.
A solution to that attitude is to do things not in a race to please others, or for the sake of doing something impressive, but for their inherent value. Doing so might require a change of one's personal value system, but it's probably a change for the better. Extreme example, but curing cancer to impress people is kind of missing the point.
Perhaps the real distinguishing factor of Matrix isn't its technology, but its governance. Instead of an extensible, plugin-based approach like XMPP, Matrix has just a single "official" spec that can only be extended by amending the spec itself. IIRC this was one of the motivations behind Matrix's inception.
As to whether one approach is better than the other is left as an exercise to the reader :) But having each approach belong to separate projects allows them to carry on as they see fit, and means they don't have to participate in a zero-sum game.
Launching with bridges to already-encrypted messengers, then immediately admitting this has to MITM them to work, doesn't make a good first impression...especially since users of these messengers will likely be more privacy-minded than most.
This is also making a bet that the inconvenience of juggling these 3 particular messengers is worth $5 a month.
IMO the real value in Matrix bridging that's been neglected (and has been mentioned elsewhere in these comments) is connecting different messengers _to each other_. Being able to connect friends/family scattered across different, otherwise-isolated protocols with a single "just works" tool is a much clearer value proposition than what feels like just another multi-protocol client.
Alas, getting that kind of multi-connectivity is tricky...as is VoIP bridging, which this doesn't support either, but should be considered as crucial for any Matrix bridge.
I don't doubt Matrix/Element will get there at some point, but for now this feels a tad premature.
a) Agreed; the fact that spaces aren't in the spec is annoying when trying to stay spec-compliant and not realizing you also have to search through various GitHub issues to be fully informed. Granted, spaces have been one of the most hotly-discussed topic in Matrix development for months, so anyone interested in making anything Matrix related likely would have come across it.
b) Not true; spaces don't require room version 9. IIRC the only space-related feature that needs a room upgrade is "restricted rooms", ie. the ability to make a room accessible only to members of another room/space.
Middle-clicking or Ctrl+clicking the New Tab button does inherit the current container. It also opens the new tab to the right of the current tab instead of at the far right of the tab strip. These actions are one in the same, so any extension that opens a tab to the right of the current tab (like Always Right or All Tabs Helper) also make the tab inherit the current container.
It's strange that such a useful feature is barely advertised at all in the UI, but it's there.
But your other criticisms of using containers as profiles are spot-on.