100%. I think the article makes space for this, too. In 3, 4, and 5 the author describes the experience of bouncing off of something despite trying to like it as well as _thinking_ you like something despite not _really_ liking it. Both types of experiences resonated with me.
I think the key here is that you did try, you gave cooking and sports an honest chance, and it turns out that you're not into them. It doesn't feel like many people would put the effort in to really figure out if they _would_ like something that's initially uncomfortable or difficult. I think that's what the article is responding to - I read the overall thesis as "you might actually end up liking something that you don't like initially" rather than "you will like anything given enough effort".
Will I finally be able to ask my car factual questions while driving? Right now android auto's assistant experience is way worse than on my phone or watch, so I end up having to use one of those (if it's important enough, otherwise I just forget).
Based on a cursory search, I get the impression they haven't solved the particular cleaning problem the author did (i.e. removing places that just have restaurants rather than actually are restaurants). In one case on my food & drink list I have a place that is very highly reviewed, but is actually a museum; I doubt the reviews refer to the restaurant specifically.
It is interesting to play with though. Thanks for the reference!
Apologies if my timings are off in this comment. They should be close enough to make my point, but it can be hard to find the actual dates.
I have run a Synapse server for almost 8 years, by my reckoning. For most of that time I have been a $15/mo supporter.
For several years, I had been hoping Dendrite would be released, along with a migration path to get my users over there. Synapse's resource usage is not great. I do run workers in order to improve performance.
I'm waiting for an official migration path because I don't want to have to migrate my community again like I did when we moved from Slack to Matrix. It takes a lot of work just to move people over, and you always lose a couple people, which is a serious cost.
Early last year I learned that they had put that on ice due to money issues. So there wasn't much hope of moving to a lower-cost Matrix implementation without a lot of headache. This makes sense. Building a homeserver implementation while maintaining an older one is expensive.
For a year or more we've had quite a few blog posts saying that there's not enough money and that large organizations join the Matrix Foundation. This makes sense. Those organizations have enough money to keep it going, unlike my small monthly donation, which doesn't really matter all that much in the grand scheme of things.
It's been quite a while since we've seen a new user-facing feature, and longer since we've had a selling point (which I could use to answer the question "why should I move to Matrix?"). It makes sense to prioritize functionality over new features, particularly when you've got a limited budget. But we still don't have some features which are very popular in Discord and Slack, like custom react images; these are implemented in other clients, like Cinny, but not Element.
Last year they released Sliding Sync in Synapse, deprecating the Sliding Sync Proxy which I had been running to support clients who wanted to use Element X (a new client implementation). I personally haven't switched since Element X does not support Spaces. Moving Sliding Sync into Synapse saved me some resources supporting those clients. It was a little hard to tell when it was safe to remove the Sliding Sync Proxy; I had to track a couple Github issues. Matrix used to have a public roadmap, but it's no longer updated, so it's hard to keep up with the status of different features in development.
After that they released Matrix Authentication Service (MAS), which is an additional service to deploy that moves the internal authentication functionality out of Synapse and interfaces with Synapse using OIDC. I haven't deployed it yet. They say it will eventually get rolled into Synapse, so I'm intending to wait for that.
All in all, it does not feel like the things I want, and (assuming I'm not a completely unusual case) that the community wants, are high priority for the Element team. Donations the size of mine don't make a difference for their budget. They're spending what budget they do have on refactors like MAS, which don't seem to impact usability (though perhaps they do if you have a massive homeserver). They spend time and effort supporting new features which make Element X faster (Sliding Sync) but have not yet implemented all the core functionality (Spaces) so there's not much reason to move.
I concluded a few months ago that our interests are not aligned any more and stopped donating. I know I'm not owed anything for my donations. I donated to support a project which I was excited about. This announcement, and that RAM graph which I will never see on my own server, makes me confident in discontinuing my support.
I do not feel like Matrix/Element values its community any more.
I feel the point is a bit subtler. We should strive for improvement. We should also understand that that takes more than the normal amount of resources to do something different and better & either commit to spending what's required or, if we can't afford to, use something already proven instead.
The half-done or broken improvements still get called "innovations" and give innovation overall a worse reputation.
That seems like the real problem with Spotify shuffle. The thing that feels un-random about it is that it plays the exact same songs over and over again despite the humongous size of the playlist. It's not that it plays the same artist, or that every once in a while you get a repeat song. Once you get one repeat they're all repeats.
I wish it would randomly pick the next song from the entire playlist whenever it changed songs.
Though as you say it might already be doing this now. I don't remember feeling like I'm rotating through the same 30 or so songs recently. But also I did start working around it, so I may just not be noticing.
The discount rate is doing a lot of work here. There is a discount rate such that we're not talking about shortsightedness. Getting it right is difficult. But as an example, how much would you buy an investment that pays a hundred dollars, guaranteed, next year for? Trivially, the discount rate includes at least the expected amount of inflation; it's not worth a dollar.
For assets line like IP you have to factor in how risky the returns are, how much investment you'd have to make to see them (e.g. making a movie), and overall strategy (do we want to be in that line of business).
All this to say - if you have IP that pays 10 million a year, you can value future returns on that IP in today's dollars. If someone offers you more than that to buy it, you should take the deal; you come out ahead.
As a Neovim afficionado - I think you lose some credibility recommending it as an alternative to VSCode and Sublime. They're different beasts. I imagine a lot of people would be immediately turned off if they were expecting a VSCode/Sublime-like editing experience.
Then you run into the differences between implementations. No one implements the whole standard.
The company I work for had a bug driven by the underscores-in-numbers and scientific notation functionality (`20230101000000_e111111`, a timestamp underscore a git short hash, was parsed as a huge number rather than a string). The serialization library from one language did not implement those features and so did not quote the value in its output, but the deserialization library in the other did and would parse it as a number. This eventually resulted in it becoming null (not sure why, maybe it was too large for the int type in the target language?) but even if it hadn't been we then format it into a URL (to download an artifact) so the fact that our YAML libraries disagree would cause the string value to change and break the download.
The YAML standard is too big, resulting in only partial implementations, and the disagreements can result in unexpected value changes. With no handcrafting whatsoever.
Some of the interest rates I've seen on federal student loans - 7+% - seem exorbitant in general but particularly because the lender takes no risk.
7% interest on a loan in a year with 3% inflation (the real cost of having money that year) that is guaranteed to be repaid seems like evidence of corruption to me. But maybe I think too simplistically.
For ESP chips in general, the Rust on ESP Book [0] is pretty solid. Little short. I've been playing with writing a Watchy firmware in Rust (Watchy uses the dual-Xtensa ESP32-PICO-D4), and this was a great starting point.
The alternative here is that people are more of a burden on the community, not less. It's more disruptive to have noobs asking the same questions and having to be answered by community members every time. At least from where I sit.
I don't think asking noob questions makes you part of the community in the way it matters here - actually contributing.
I think this is a bit more subtle, and a bit less interesting to say, than you're thinking it is and responding to. You need to be impure in OOP world but not in every function you write. I write many pure functions in my OOP work; they make the whole thing easier to reason about.
The FDA thinks similarly. In late 2021, they canceled trials of Paxlovid because it was immoral to have a control group. They did not then _waive the trial requirement_, meaning Paxlovid was both too proven to deny but too unproven to be administered.