Damn I better go stockpile pea-based mince(d meat).
(If you haven’t tried it before, seriously, do. There’s so many (traditional) recipes with minced meat for which this is a 1:1 replacement, it opens up an entire new world of cooking for vegetarian/vegan kitchens.)
Because a commit should be an “indivisible” unit, in the sense that “should this be a separate commit?” equates to “would I ever want to revert just these changes?”.
IDK about your commit histories, but if I’d leave everything in there, there’d be a ton of fixup commits just fixing spelling, satisfying the linter,…
Also, changes requested by reviewers: those fixups almost always belong to the same commit, it makes no sense for them to be separate.
And finally, I guess you do technically give up some granularity, but you gain an immense amount of readability of your commit history.
This comment section is… something.
If you host the bridges yourself, it makes no difference to privacy.
It’s simply convenient to have all chats in one place 🤷🏼♀️
Same. And even if you were to fuck up, have people never heard of the reflog…?
Every job I’ve worked at it’s been the expectation to regularly rebase your feature branch on main, to squash your commits (and then force push, obv), and for most projects to do rebase-merges of PRs rather than creating merge commits. Even the, uh, less gifted developers never had an issue with this.
I think people just hear the meme about git being hard somewhere and then use that as an excuse to never learn.
Grew up on it. My dad set up a Ubuntu 4.10 PC for my brother and I when we were 3/5 (no internet, obv), and it stuck.
Used Windows for a brief time in highschool to be able to play online with friends.
Went right back to Linux when going to university. Will never change back, both for ideological reasons and because Linux is just better.
Next step: NixOS on a phone
You will simply not be able to install anything, unless the FOSS dev is cool with providing their ID to Google, and agrees to its ToS, and Google likes the app and signs it.
Which many devs (myself included) will definitely NOT be.
TBH, it sounds like you have nothing to worry about then! Open ports aren’t really an issue in-and-on itself, they are problematic because the software listening on them might be vulnerable, and the (standard-) ports can provide knowledge about the nature pf the application, making it easier to target specific software with an exploit.
Since a bot has no way of finding out what services you are running, they could only attack caddy - which I’d put down as a negligible danger.
My ISP blocks incoming data to common ports unless you get a business account.
Oof, sorry, that sucks. I think you could still go the route I described though: For your domain example.com and example service myservice, listen on port :12345 and drop everything that isn’t requesting myservice.example.com:12345. Then forward the matching requests to your service’s actual port, e.g. 23456, which is closed to the internet.
Edit: and just to clarify, for service otherservice, you do not need to open a second port; stick with the one, but in addition to myservice.example.com:12345, also accept requests for otherservice.example.com:12345, but proxy that to the (again, closed-to-the-internet) port :34567.
The advantage here is that bots cannot guess from your ports what software you are running, and since caddy (or any of the mature reverse proxies) can be expected to be reasonably secure, I would not worry about bots being able to exploit the reverse proxy’s port. Bots also no longer have a direct line of communication to your services. In short, the routine of “let’s scan ports; ah, port x is open indicating use of service y; try automated exploit z” gets prevented.
I am scratching my head here: why open up ports at all? It it just to avoid having to pay for a domain? The usual way to go about this is to only proxy 443 traffic to the intended host/vm/port based on the (sub) domain, and just drop everything else, including requests on 443 that do not match your subdomains.
Granted, there are some services actually requiring open ports, but the majority don’t (and you mention a webserver, where we’re definitely back to: why open anything beyond 443?).
Client side, under advanced:
That’s a setting
InfCloud. Works well with Radicale, and does contacts, too.
It’s not pretty, but works very well for the 5/100 times I want to check through a browser instead of Calendar app / Thunderbird.
I hope forgejo’s federation efforts come along. Being able to host projects on my own instance, yet receive contributions without having to allow people to register on my instance, would give me the push to completely abandon Github.
Some might say interconnecting everything could be a legitimate goal. Nonetheless, some people started to report about huge amounts of data and metadata being sent to Matrix central servers.
Curious that this claim is without source in the original.
I also have porblems with their claims about bridges. Bridges are Band-Aids to allow you to communicate with people not on Matrix, not a dark masterplan to build a central spionage hub.
By default, a homeserver trusts matrix.org in questions of federation and identity of other servers. You have to get that trust from somewhere. You are free to choose another source for that.
(For example, my homeserver isn’t federated at all, and has that trusted server removed; it doesn’t communicate with anyone. Also it’s not synapse, but that’s besides the point.)
Please beware that DNS over TLS is transport protection; the dns server itself of course still sees and knows everything.
How exactly does Free, non-open-source software prevent that?
Piefuckers
Pffft. You just aren’t a Nix enjoyer yet.
Lol, exact same situation here.
Quick question, did the migration to continuwuity break calls for you as well?