Also:

  git status --ignored
  git clean -ndX # preview what would be removed
  git clean -fdX # actually delete the files (warning: destructive)

(You have lost the plot; your response amounts to explaining how soap and water works to someone who has just described their office mate's tendency not to shower.)

Also you can do `git status --ignored` and it will list all files changed, even if ignored. If that is really your main issue.

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.

I don't see how that's possible without turning the language into something that isn't C, either by adding significant new functionality (e.g. fat pointers) or subtracting enough functionality that it's a much less capable language (e.g. disallowing dynamic memory allocation).

An important improvement over rust is that "Fil-C has no unsafe statement."

In case of fil-c, it is about 1.5-4x slower performance, and a memory overhead.

So, let's not present it as a panacea to all problems: there could good reasons to use it, but it isn't a magic trick.

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.

How many people consuming text via rss the same way people consume audio via podcasts?

We're talking about text here. We all know how this sentence ends, "You should start a ..." and it isn't rss feed. Everyone used to have a blog and nobody really cared. Now everyone has a podcast and (more) people do. People don't know what an rss feed is.

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.

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.

Assume you did some local LLM stuff in June that worked with a 200MB set of various jpegs and you wanted to keep it private: Is this still legit in September 2026? I wouldn't rely on it.

Yeah, I think this is a win-win for both parties.

You strike me as someone who would "ride along the lines of the terms of service" basically, and you'll see anything not explicitly forbidden as being allowed essentially.

While Codeberg is a project driven by humans, with human reactions to what's happening. If you're not comfortable with rules not being 100% defined, and requiring a humans value judgement to be had to figure out if the rule is broken or not, I don't think Codeberg is for you.

The rest of us, who are OK with humans making decisions rather than just going by what's written in rules, are fine with this, because we know our private repositories won't be deleted. And if they are, you'll be able to speak with a human to explain, and if your intention is fine and good, they'll be OK with it. But if you try to argue about some "That wasn't explicitly stated", then yeah, they'll probably get tired of you quickly.

Think your participating in your local user group vs some corporate/government forum, the rules will be enforced differently.

By using AI to write code, like virtually everyone does? Tell me, what indication was there in their TOS, that this might be close to a line?

> You must not share projects that mostly consist of code written by "generative AI"-tools (including services such as Claude, OpenAI Codex). Such projects having an unclear copyright status (see requirements § 2 (1) 1 and § 2 (1) 3) and furthermore have little safeguards to ensure that they do not include harmful code (c.f. § 2 (1) 5).

At least stick with the truth before launching with "the right the to do" (which is also a pretty bad rule because it's completely ambiguous.)

Ambiguous rules with clear objectives is what gives a non-profit the power to be flexible in the way to accomplish common goals. It's based on human trust and is fine by me and others. If you ever were part of a non-profit, you know human trust is an essential component.

What does "made up" mean? It was a decision by the actual members of the platform, you know, the actual people using it! Nothing "made up" about it.

I think it's pretty clear you don't have an idea of what Codeberg is trying to be, nor do you have any interest in understanding, you just want to push this "Codefloe" platform for some reason. Codeberg make very public what the platform is for and yes, that'll change in the future too, as the world changes.

The reason I'm supporting Codefloe is written in the comment you are responding to. Codeberg is not interested in hosting all FOSS, and Codefloe is. That is the reason. Its very simple.

It is pretty clear you are not making any effort at all to understand the problem people have with Codeberg's rug pull.

There are people who don't understand that and crank out slop. Fuck those people. That isn't what I do.

There are people who don't understand that and won't host my FOSS. Well, I've found someone who will.

They recently made some very ideological decisions…

That doesn’t work because „fine and good“ doesn’t mean the same thing to Codeberg voters/admins and to a large part of the hacke news population. Notably, Codeberg is morally opposed to AI.

Why on earth would Codeberg give even the slighest fucks about what the "hacker news population" finds "fine and good"? Makes absolutely zero sense.

Codeberg made those things against the Terms of Service because paying members who use the platform voted for exactly that. This is how Codeberg works, the members of the platform decides how it works.

Do I trust humans behind Codeberg to behave sensibly? No.

Would more precise terms of service that explain what Codeberg community thinks is ok help with such trust? Yes.

Should the humans behind Codeberg care what I think? Maybe? Presumably they do care about reaching _some_ users, otherwise why have the service public at all?

> The rest of us, who are OK with humans making decisions rather than just going by what's written in rules [...]

Better speak for yourself and not infer from your own views to others. With bad intention this could be interpreted as if I was incapable of dealing with human decisions when all I stated is that I mistrust people who rugpull me.

So, not code for personal projects? Right? A private git repo with my own code, is not permitted.

More to the point of this thread - there is no specific affordance for a personal website.

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.)

The terms of service state:

> Private repositories are only allowed for things required for FLOSS projects, like storing secrets, team-internal discussions or hiding projects from the public until they're ready for usage and/or contribution. They are also allowed for really small & personal stuff like your journal, config files, ideas or notes, but explicitly not as a personal cloud or media storage.

The TOS Section 1:

> Our service is open for all projects covered by a licence for free and open source software, free and open source hardware, or free cultural works as defined by § 2 (1) 1.

So the "FUD" I am spreading is literally the headline of the legal terms of service. There is an organization behind the spread of this information, and it is Codeberg e.V.

"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.

In the remoteStorage protocol, providers have been instructed to ignore client_id in lieu of identifying the connecting app by its origin.