Right. Because compute power and/or a physics based model is the limiting factor for accurately predicting when a seismic event happens. Training on historic data is hardly the problem that need's solving.
It's the leading indicators that are actually measurable that are missing. You know the ones that allow for evacuations and other protective measures.
I saw beta screenshots of what used to be the toolbar (e.g. in Finder) and immediately disabled auto-update on my Mac. Seeing how many bugs have also been introduced (not just visual glitches) pretty much reaffirmed me in my decision.
However the downside is I can't try some new app releases like Daft Music[1] because it has become to burdensome to maintain two different designs. Especially in SwiftUI.
Trust me 1-Star-Drive-By Reviews by "customers" without any merit are just as bad for businesses.
So, congrats. You've basically discovered that online review systems suck. Look at app stores. Look at Amazon product reviews. It's all being gamed and manipulated and abused. Google obviously won't moderate any of this because there's no substantial business value.
I'm of the opinion that this is bad design because it makes it very hard to reason about the consequences when refactoring a large codebase. It's kind of like reactive global variables. There are legitimate reasons when to use them. But not as a general design principle.
That being said: If you're dead set on this paradigm you can implement this easily yourself. Create a bootstrapping function that modifies a prototype or class in order to provide functions to register signals and slots and use them wherever you need them.
If you use TypeScript you could even use Decorators (e.g. "@Signal" or "@Slot") which are just higher order functions to have some syntactic sugar like the QT macros.
> The irony is that, since you are splitting the problem in a way that requires synchronization between cores, you are actually introducing more work to be executed in the same CPU-time budget. So you are spending more time on overhead due to synchronization, which does the opposite of what you probably hoped for — it makes your code even slower, not faster.
That is certainly not universally true for every scenario and if you need to sync state between cpu cores very often then your tasks simply don't lend themselves to parallelization. That doesn't mean that multi-threading is inheritely the wrong design choice. Of course it will always be a trade-off between performance gains and the code complexity of your job control.
But people new to thinking about concurrency don’t know this. They write “parallel” code that goes pretty fast, and that initial reward convinces them to continue. Then the bugs are found, and their parallel code gets slower, but that’s just bug fixes. Never mind the performance loss.
John has reiterated multiple times on his podcast that he doesn't want to deal with thousands of support requests when making his apps open source and free. All his apps are personal itches he scratched and he sells them not to make a profit but to make the barrier of entry high enough to make user feedback manageable.
Absolutely no judgement for however people want to licence and distribute their software, but I've seen the support burden used as justification for closed source/selling software quite a bit recently, and wonder how often people might be conflating open source with open development. There's no reason an open source project has to accept bug reports or pull requests from anyone. See SQLite or many of the tools from Fabrice Bellard for example.
Again, I've got no problem with people selling software or closed source models, but I've never understood using this justification. Maybe in this instance he's a well known public figure with published contact info that people will abuse?
Didn’t SQLite developer(s) famously receive a flood of phone calls because McAfee antivirus used it in a way that was visible (and “suspicious”) to its users?
> he doesn't want to deal with thousands of support requests when making his apps open source and free.
Who says you have to deal with support requests if you open source something?
> All his apps are personal itches he scratched and he sells them not to make a profit but to make the barrier of entry high enough to make user feedback manageable.
> Who says you have to deal with support requests if you open source something?
Almost anyone who has ever maintained popular open-source software, even if dealing with them means putting up a notice that says "Don't ask support questions" and having to delete angrily posted issues.
My understanding from listening to his explanation is he wants to be able to support users and have an income stream to incentivize that.
As an open-source maintainer of a popular piece of software, I'm very empathetic.
There's a lot of merit to Open Source. But there's also a lot of spam, politics and drama that comes with opening up. That negativity is invisible to people who haven't encountered it, or are simply guilty of causing it.
Maintainer burnout is real; more power to John for choosing whatever keeps him focused on building good software.
> Almost anyone who has ever maintained popular open-source software, even if dealing with them means putting up a notice that says "Don't ask support questions" and having to delete angrily posted issues.
I mean, that's very obviously a false statement. You don't have to post any notices or reply to or delete any issues.
> My understanding from listening to his explanation is he wants to be able to support users and have an income stream to incentivize that.
That's valid, but is basically the opposite of the reasoning provided in gp comment.
Sorry, that's a BS reason. If you don't want that, just ignore all opened issues. That's it. If you are nice then you put a README that explains this in a sentence or two. If a community forms that wants to fix issues, for example critical ones that could lead to data loss then the community will deal with it, e.g. by forking.
Just keeping everything closed is really missing the point of how trust in infra that handles critical data is built nowadays.
As I understand it, from listening to the podcast, a better summary is that if it becomes popular, he wants it to be worthwhile for him to keep working on.
Apps like this can easily bit rot, and more users does often mean more work e.g. answering or filtering emails, finding more edge cases, etc.
From his perspective that means having a income to dedicate time to this. I don't think he's interested in being an "infra" app as you would think of it.
As someone who maintains critical open-source software, I can strongly empathize, even if it’s not an approach I would take.
I still maintain that if that's the case then something is wrong. More users reporting bugs for relevant edge cases is not a nuisance, it's the crowdsourcing of testing and each such reported issue is gold because then he can fix it before he as a user of his own software runs into it. Assuming he actually uses the software. (I also do maintain a bunch of packages and I do use them daily.)
Making software proprietary and for-pay, especially such a small tool, doesn't just significantly reduce the number of eyeballs this testing is crowdsourced to, but it also disincentivises issue reporting .. why should I spend the time to for free report sth to somebody who is making money off my testing and doesn't even bother to be transparent about how things work exactly (i.e. the source)?
If you really care about the quality of your work then maximizing the eye ball count and incentivise high qualith issue reporting.
Though if you want to maximize income instead, you keep it closed and ask for a subscription.
> why should I spend the time to for free report sth to somebody who is making money off my testing and doesn't even bother to be transparent about how things work exactly (i.e. the source)?
You don’t have to. No one is saying you are compelled to report bugs in software you paid for. Most people don’t. The benefit to you as a customer is it can help get the bug fixed. That is clearly a mutual benefit.
> If you really care about the quality of your work then maximizing the eye ball count and incentivise high qualith issue reporting.
I think you’re vastly overestimating the value in the “higher quality” bug reports you’re getting from free users. You might get some higher quality reports but you’ll mostly get a lot more noise.
You're vastly overestimating how the norms of GitHub are able to account for how things have to be. Recognizing that GitHub's userbase has a certain type of problem is no different than realizing that HN, Reddit, Tumblr, etc. all have their own respective userbases and each tends to behave in certain ways (desirable or not) that are characteristic to that group.
It's not about the meta-characteristics of a user base. By allowing anyone to create issues, you are creating additional noise. Even if the signal to noise ratio were to be higher, you're still increasing total noise.
There are limits to how practical it is to allow for more and more feedback and that threshold for a solo developer is quite low. Restricting your user base by charging for your work means that there is less noise because the only people sending bug reports are paid users.
The quality of these reports are probably lower than if you had an open issue tracker, but you are substantially reducing the mental overhead and you know the people that are sending feedback are doing so with their own interests in mind.
At any given time when I'm at a restaurant or grocery store, there's more food around and on the menu than the threshold for how much food that I as a single person can eat.
At a grocery store or restaurant, there’s no expectation that I examine every item individually, nor am I responsible for organizing the options categorically. Those are already handled for me by the establishment. My only responsibility is to navigate the choices and make a selection, and even then, there’s no 'wrong' choice, per se.
An issue tracker, on the other hand, requires active engagement from the developer. Every issue, even low quality ones, require some form of processing, be that responding, closing, or categorizing. While tools can assist a person in these tasks, the developer is ultimately still responsible for it.
I'm not saying people should only create closed-sourced paid software, but I strongly disagree with the idea that it's negatively affecting the quality of the software because there's no open issue tracker for people to post to.
It's not just github. It's every single issue tracker where users can submit feedback, some of which are almost entirely opaque, like Apple's feedback system. Look at Mozilla's issue tracker, or look at the mailing lists for linux. It's a lot of effort which simply is not worth it for a lot of people in a lot of cases.
> An issue tracker, on the other hand, requires active engagement from the developer. Every issue, even low quality ones, require some form of processing
It's the leading indicators that are actually measurable that are missing. You know the ones that allow for evacuations and other protective measures.