Boy, those pesky emotions! Surely that's the culprit here, and not self-assured HN commenters showing up to hand out /r/confidentlyincorrect-tier advice that still wouldn't address anyone's problem even if it did work.
5,400 karma · joined August 24, 2019
-- Richard Feynman. Interview broadcast on BBC, 1981.
And `rm ./.gitignore` will, predictably, leave the tree without a ./.gitignore (i.e., the desired state) whereas `git status --ignore`, uh, won't.
> The symlink creates what is effectively a version-controlled gitignore
No, it doesn't—like I already said. The ln(1) invocation you wrote is not going to work. As written, it contains two glaring errors obvious on sight to anyone who actually has enough experience with the particulars of /bin/ln and Git and how repos get populated with a default .git/info/exclude.
> My comment and the other replies show you how to use git
Oh, gee, thanks!
I don't know you think that will do or how symlinks work, but it won't lead to anything relevant to this discussion. (To answer your question: no.)
That's because the original sin of GitHub "wikis" is that they weren't (and most of them still aren't) even wikis. There's this perverse thing that happened during the wiki age, where people unable or unwilling to get on board decided to just start calling things "wikis" even though they exemplify the very thing that the wiki was invented as a response to. The reckless debasing of the word then infected adjacent spaces. Sourcehut's "read-only wikis" (wat) aren't even designed to be edited in the browser; on Sourcehut, "Publishing your changes is as easy as committing them and pushing them upstream." Newsflash: That's not a wiki.
This is both true and also if followed would fly in the face of what XMPP (and the Mastodon-flavored ActivityPub-powered fediverse of microblogs-and-more) is supposed to be about. And it's also both true and yet people understand what "email" means and how to use it without constantly and consistently running into issues trying to bang out a reply to alice@gmail.example even when the sender's inbox is hosted @yahoo.com—nor do folks spend much time thinking about how and why AT&T's SMSes (for example) are able to make their way to their friend's device even though they use Verizon (to give another example—and if they even know which provider their friend uses at all).
One thing that Jabber (and, later, Mastodon) did wrong was to take the unfortunate stance that it wouldn't be too big of a deal to adopt email-like identifiers without actually being email or implying that Internet-standard email services are available; it was felt that users would just be smart enough to adapt to it. This was a mistake.
The confusion with email, though, can be exploited as useful momentum—something that the network has going for it, instead of a flaw.
If the author and the rest of the Jabber/XMPP community wants the public to "give Jabber/XMPP a shot", then it probably does need (a) a flagship instance (a la mastodon.social) that controls multiple domains (the way that many email providers like Runbox or Fastmail do) and requires the user to pick which one they want their handle to be associated with at signup, in order to introduce email-like decentralization to the userbase as early as possible, and that (b) raises the bar by setting a standard among Jabber/XMPP instances and actually offering email services to that userbase (prior art: Google married (XMPP-based) Gtalk with Gmail in the early days).
While undertaking all of this, an effort to update the XMPP protocol (a la JMAP, but in a backwards-compatible way) while simultaneously reconciling it with legacy email (also in a backwards-compatible way) wouldn't hurt—where "backwards-compatible" here means "to gracefully degrade and provide a fallback" (prior art: Delta Chat).
I'm a former Mozillian and a lifelong Firefox user (continuously since Firefox has existed, at least). I know Firefox is slower. I can feel it and have felt it on every system I've ever owned, and am constantly reminded once every few months or weeks or so when I open up Chrome to check something and am confronted with how much snappier it is—even without an ad blocker, which I don't have installed because I don't actually use Chrome.
I know all this and I use Firefox anyway because I don't care.
What I don't do is go online and comment about how there's no difference when there is clearly a difference. Pretending things are otherwise comes across as some form of denial or delusion.
I don't know what this means. I'm guessing the correct answer is supposed to be "podcast"? Even so, weird false dichotomy.
That looking at tweets and listening to podcasts is more popular than reading long-form blog posts via RSS has a lot more to do with people's revealed preference for looking at tweets and listening to podcasts versus reading long-form blogs than it has to do with RSS.
(The actual context was delivery of notices by public services through non-Twitter feeds, anyway. Not blogging.)
> People don't know what an rss feed is.
I don't know why you think this is relevant here. It seems that when you're referring to using "RSS", what you mean is for people to care about RSS—in the way that Gemini, Secure Scuttlebutt, etc. have always been about caring about (and almost exclusively using them to talk about) Gemini, Secure Scuttlebutt, etc. than they ever were actually expected to be used organically and non-self-referentially.
The fact is that people (already/still) use RSS today. It hasn't been defeated. And Twitter could turn into an RSS-based feed reader tomorrow that works basically the same as it works today, and then suddenly everyone would be using RSS but no one would drop out because of it. Because people don't know (read: care) what an RSS feed is.
"Codeberg does not permit personal repos"
"A private git repo with my own code, is not permitted"
Codeberg's policy explicitly permits personal repos, including private code repos. Both of your claims are false. There is no getting around this, no matter how much you try to move the goalposts or the other forms of conversational misdirection you're trying to pull off here.
"Codeberg does not permit personal repos"
"A private git repo with my own code, is not permitted"
Codeberg's policy explicitly permits personal repos, including private code repos. Both of your claims are false. There is no getting around this, no matter how much you try to move the goalposts or the other forms of conversational misdirection you're trying to pull off here.
No, not right. Still wrong:
"Use it for your personal notes, your side project or any other[sic] you want to keep private".
(That's even ignoring that I was addressing the claim that you actually made, which is different from the one you're making now; you're moving the goalposts.)
Both personal and private repos are explicitly permitted in the Codeberg TOS:
> Private repositories[…] allowed for really small & personal stuff like your journal, config files, ideas or notes, but explicitly not as a personal cloud or media storage.
In the remoteStorage protocol, providers have been instructed to ignore client_id in lieu of identifying the connecting app by its origin.
* or arguably the same amount or less; for additional context: the author is an ex-Googler
In any case, nowhere is it indicated why this approach (no matter what you call it) should be preferred over e.g. recfiles.
1. I am not Codeberg.
2. Turning away people doing unwanted things is the whole purpose of Codeberg's new policy. Why you present this as a undesirable side effect rather than exactly what the policy was designed to do is the only difficult thing to comprehend in this thread.
No, they didn't. That's not what the blog post says.
> You can read it yourself
I didn't fail to do the reading beforehand. I posted a direct link to the change in the TOS and which is currently linked at the top of all Codeberg pages. Can you read it yourself?