I did a bit more homework and you're right.
"Back in the day" running Javascript increased your attack area. But now-a-days I guess it's consider "safe".
I did find this old (7 years ago) posting which talked about concerns. Today, I guess the rule of thumb is to avoid (or limit) browser plugins.
Thank you clarify that.
But the nice thing about email is it's decentralized, and everyone already has it.
That is true, but in the case of email as an issue tracker: only the people who have received it will know of its existence (unless it's mirrored on public facing websites - like Debian does with their issue tracking).
The thing we'd lose is the "ease of access". Tbh, I'd see Usenet being a better distribution medium than email for OSS apps... but I really appreciate the intention behind solutions like git-issues: move the issue tracking into the same tools used to track code changes. It, in my opinion, is more in line with K. I. S. S.
You make a valid point regarding losing important contextual information like PR and open bugs.
However, I don't think email offers the same level of visibility as we currently have with github workflows.
There is an creative Git based issue tracker, I used called git-issue. Basically, the entire bug/issue/pr process is captured as yaml (I think) files, which are kept in a dedicated branch.
When I used it (as I wanted a self-hosted bug tracker), I found it functional but a bit cumbersome. However, I could see someone creating a very nice github like web interface for it.
I like the idea of improving the quality of "what's hot".
At the moment, the current implementation is pretty weak. Even in this thread, as I'm reading it: Your post is top... even though it's 25 minutes old and has only 3 upvotes, compared to the second thread which is an hour old and has 39 upvotes.
I can see how Lemmy would benefit by modularizing the "hot" algorithm. This would allow each Lemmy server to install/test their own (or shared) "hotness" algorithm. Eventually, I think, everyone would converge but in the meanwhile it would allow for a rapid exploration of different possibilities.
You've got a good point regarding Photoshop. Gimp exists on Linux, but I find it immensely powerful but hard to wield.
Gaming with the Steam Desk has gotten better for Linux with the introduction of Proton and I imagine this'll only improve.
You can see if your favorite game is supported with Proton here.
I'd say, let's wait for a catastrophic event at github before we jump ship.
Git , by its nature, is distributed. If, worse case, github.com went down (without warning). Life would move on, people will have local checkouts of the "important/popular" repos that would be pushed "somewhere else".
Yeah, github actions wouldn't work, build that pull from github repos would need to be refactored, but life would move on.
I found traefik to be a more feature rich, load balancer when used in kubernetes environments. Other than use in kubernetes, I'd say if you're happy with nginx, keep using nginx :)
"Be kind, rewind"
Thank you for the clarification. I was also confused by that quote (ie: if you can control who's data your reading... you should be able to control who has access to your data. Of course, this doesn't include mirroring content and other shady practices, but I don't think Meta would go down that path to avoid being defederated)
It's also perfect if you spend time on any remote machines. The default configuration isn't awesome, but it does "get the job done".
Um.. How about "... their money..."?
Hey congrats, that's quite an accomplishment. I bought the game from Steam and spent 2 hours struggling to get through the tutorial... which I failed.
I ended up returning the game. I still have it on my wishlist, but I'm going to wait for it to reach some epic all time low price, before I subject myself to that level of suffering (and growth) again.