LibreOffice, because it is local. If I want to collaborate, I’ll share the file in whatever way is most convenient for the other parties. Since most people I collaborate prefer editing locally, this works out quite well.

If any repository that you use, or are interested in, is hosted on a commercial, for-profit service (even if it has a free tier), back it up. It will, eventually, disappear.

None, because they typicially open up a larger attack surface than the system would have without them. It’s been like that for a while now. For references, I’d recommend this article from Ars Technica, who reference some very knowledgeable people (including Chrome’s Security Chief at the time).

There was a time when AV software was useful. We’re a decade past that, the world has changed, software has changed, defenses have changed, and AV software did not keep up.

What is stopping someone; say the FSF or some other group championing libre software from coming up with their own web engine completely different from the incumbent engines?

Building a browser engine is hard, especially when the target is moving at a rapid pace, and that target is controlled by Google. Like it or not, the web as it is today, is pretty much driven by Google (and to a lesser extent by Apple and Microsoft) these days. They can throw infinite resources into developing the browser engine and the browser itself. The closest competitor we have today is likely Servo, and they scrape by on pennies.

Developing something from scratch, with even less funding and expertise than Servo is a non-starter. It’s not going to happen. Sure, sure, there’s LadyBird and some other independent efforts, but I very highly doubt they’ll ever catch up to the three major engines.

To develop and maintain a browser, you need people, and they need to be paid. Paying open source developers is… quite a big problem in and of itself, even for things considerably easier and smaller in scale than a web browser.

surely if Web Devs tell them to go pound sand, or intentionally break the site when using Google Chrome, and put a message saying, “Go to Firefox / Safari for a better experience”, that will make Google backtrack.

They would not, because for every developer who would do this, there’s 100 who would not, because their livelihood depends on people with Google browsers being able to use their stuff. Google is in a position of power here: they are the #1 search engine, they are the #1 browser, they’re pretty well positioned on the mobile phone market too. The vast majority of businesses (companies or individuals, doesn’t matter) simply can’t afford to go against Google.

If the vast majority would, then yeah, Google would backtrack. But that would require a coordinated effort, from the vast majority of the internet. Likely multiple months of protest. That’s not going to happen, people can’t afford it.

IT years are similar to dog years, an IT year is multiple normal human years, so 14 IT years is certainly IT decades.

algernon nods sagely

Sadly, that’s not code Linus wrote. Nor one he merged. (It’s from git, copied from rsync, committed by Junio)

There are no bugs. Just happy little accidental features.

It’s about 5 times longer than previous releases were maintained for, and is an experiment. If there’s a need for a longer term support branch, there will be one. It’s pointless to start maintaining an 5+ year branch with 0 users and a handful of volunteers, none of whom are paid for doing the maintenance.

So yes, in that context, 15 months is long.

A lot of people do. Especially on GitHub, where you can just browse a random repository, find a file you want to change, hit the edit button, and edit it right there in the browser (it does the forking for you behind the scenes). For people unfamiliar with git, that’s huge.

It’s also a great boon when you don’t want to clone the repo locally! For example, when I’m on a slow, metered connection, I have no desire to spend 10+ minutes (and half of my data cap) for a repo to clone, just so I can fix a typo. With the web editor, I can accomplish the same thing with very little network traffic, in about 1 minute.

While normally I prefer the comfort of my Emacs, there are situations where a workflow that happens entirely in the browser is simply more practical.

Yes.

Forgejo has no official Windows builds, and since it is not tested on windows at all, it’s not guaranteed to work.

Fair bias notice: I am a Forgejo contributor.

I switched from Gitea to Forgejo when Forgejo was announced, and it was as simple as changing the binary/docker image. It remains that simple today, and will remain that simple for the foreseeable future, because Forgejo cherry picks most of the changes in Gitea on a weekly basis. Until the codebases diverge, that will remain the case, and Forgejo will remain a drop-in replacement until such time comes that we decide not to pick a feature or change. If you’re not reliant on said feature, it’s still a drop-in replacement. (So far, we have a few things that are implemented differently in Forgejo, but still in a compatible way).

Let me offer a few reasons to switch:

• Forgejo - as of today, and for the foreseeable future - includes everything in Gitea, but with more tests, and more features on top. A few features Forgejo has that Gitea does not:
  • Forgejo makes it possible to have any signed in user edit Wikis (like GitHub), Gitea restricts it to collaborators only. (Forgejo defaults to that too, but the default can be changed). Mind you, this is not in a Forgejo release yet, it will be coming in the next release probably in April.
  • Gitea has support for showing an Action status badge. Forgejo has badges for action statuses, stars, forks, issues, pull requests.
  • …there are numerous other features being developed for Forgejo that will not make it into Gitea unless they cherry pick it (they don’t do that), or reimplement it (wasting a lot of time, and potentially introducing bugs).
• Forgejo puts a lot of effort into testing. Every feature developed for Forgejo needs to have a reasonable amount of tests. Most of the things we cherry pick for Gitea, we write tests for if they don’t have any (we write plenty of tests for stuff originating from Gitea).
• Forgejo is developed in the open, using free tools: we use Forgejo to host the code, issues and releases, Forgejo Actions for CI, and Weblate for translations. Gitea uses GitHub to host the code, issues and releases, uses GitHub CI, and CrowdIn for translations (all of them proprietary platforms).
• Forgejo accepts contributions without requiring copyright assignment, Gitea does not.
• Forgejo routinely cherry picks from Gitea, Gitea does not cherry pick from Forgejo (they do tend to reimplement things we’ve done, though, a huge waste of time if you ask me).
• Forgejo isn’t going anywhere anytime soon, see the sustainability repo. There are people committed to working on it, there are people paid to work on it, and there’s a fairly healthy community around it already.

The single best thing I like about Zed is how they unironically put up a video on their homepage where they take a perfectly fine function, and butcher it with irrelevant features using CoPilot, and in the process:

• Make the function’s name not match what it is actually doing.
• Hardcode three special cases for no good reason.
• Write no tests at all.
• Update the documentation, but make the short version of it misleading, suggesting it accepts all named colors, rather than just three. (The long description clarifies that, so it’s not completely bad.)
• Show how engineering the prompt to do what they want takes more time than just writing the code in the first place.

And that’s supposed to be a feature. I wonder how they’d feel if someone sent them a pull request done in a similar manner, resulting in similarly bad code.

I think I’ll remain firmly in the “if FPS is an important metric in your editor, you’re doing something wrong” camp, and will also steer clear of anything that hypes up the plagiarism parrots as something that’d be a net win.

I think I can pinpoint the exact date things went sideways. It was a dark day on Monday, October 1, 2012.

Oh, sure, of course, my apologies. I hope my repeated utterances of the word will not summon Raku.

…fuck, I said it out loud.

Perl is what the Great Old Ones are afraid of, for It is so vast and powerful that even a Great Old One cannot comprehend Its true power.

There are worse things out there than Great Old Ones. You might invoke Perl by accident.