Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)TE
Posts
0
Comments
29
Joined
2 yr. ago

  • If I super heat a metal and it turns visibly red what is happening? Was it already emitting infrared and as it gets hotter the frequency shifts up? Or is it still emitting infrared but has a wider band of frequencies it is emitting as well (i.e. is it emitting frequencies below infrared as well as visible red)?

  • Yeah I've played with git-issue and agree it's not ideal. Have you checked out Sourcehut? It is entirely email based but with some pretty great tooling around it to make it more accessible.

    I agree that in a perfect world we have a separate open protocol for all of the non-repository related workflows/data, that has all the features we need. But the nice thing about email is it's decentralized, and everyone already has it. And in my opinion, with the right tooling built around it, it can get pretty close to the same quality of life as a github PR, but also degrade gracefully without it.

  • The problem isn't the version control itself. Obviously git continues to function and I can commit things offline in a plane. What I can't do is create/review PRs or read/open issues. That's easy to brush off, but the most egregious thing is the fact that this used to be federated over email!

    All we needed was more user-friendly tooling to make it easier for new college grads to start contributing to FLOSS, but instead of better email based tooling we got the centralized trash that github is today.

  • The problem is all of these apps are using proprietary APIs to communicate to centralized backends, which then deprecate the APIs and the old versions cease to work. Back when software was largely communicating over standardized protocols it was feasible to run an old version of software for years after it had been stopped being maintained, but protocols don't make money, APIs do.

  • There's no way of knowing, which is the whole problem with their model and why a lot of us self host things in the first place. Even if they super duper promise not to use the data, they could be lying. And if they are actually true to their word today, that could change tomorrow.

  • I haven't used any flatpacks, mostly because they don't seem to have a good solution for running terminal programs. (Also I don't like that the application developer chooses the permissions to expose rather than the user.

    However, I have been using bubblewrap which is what flatpack uses under the hood to sandbox. This allows me to run both gui and non-gui programs, and I have the control of exposing the minimum required permissions that I'm comfortable giving an untrusted piece of software.

  • I seem to be in the minority here but I personally prefer using $ and # to denote root. I like this because not everyone uses sudo and might not even have it installed.

    That being said, if you already have other commands that are using sudo -u ... to run commands as a different user then it might be best to just be consistent and prefix everything with it, but if there is only a few of those maybe a # cp foo bar && chown www-data bar is an alternative.

  • it has a nice working sync of connection profiles (even of ssh keys…encrypted!)

    Sorry, but what on earth does this have to do with a terminal emulator? Something like this makes way more sense as a separate tool. It's like if I was making a decision of what video player to use because it can sync my browser bookmarks.