I think the first thing to figure out would be why udev is getting shut down. Perhaps you could extract its logs? journalctl -b -u systemd-udevd.service should do the trick. This gets you the logs of the current boot’s udevd service.

Once you know why it is shutting down, it will be time to figure out how to stop it from shutting down. That should, hopefully, fix the problem you’re having.

If I’m working for someone else (company or otherwise), I’ll write comments and docs in whatever language I can speak that they want me to (which pretty much means I write comments in English, because I rarely work for Hungarian companies nowadays, and even the ones I did work for preferred English, and these are the only two human languages I can write :().

When working on my own projects, it is always English, because Hungarian doesn’t have good translations for many of the technical terms, so half my comments would be English borrowed words anyway. Might aswell write the rest in English too. Also makes it easier for others to chime in, because there are a whole lot more people speaking English than Hungarian.

It was harder in the beginning, when my command of the English language was far worse, but even then, half-Hungarian/Half-English comments just looked weird, and more jarring than full English, even if that English was kinda bad.

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

There’s plenty, but I do not wish to hijack this thread, so… have a look at the Forgejo 7.0 release notes, the PRs it links to along notable features (and a boatload of bugfixes, many of which aren’t in Gitea). Then compare when (and if) similar features or fixes were implemented in Gitea.

The major difference (apart from governance, and on a technical level) between Gitea and Forgejo is that Forgejo cherry picks from Gitea weekly (being a hard fork doesn’t mean all ties are severed, it means that development happens independently). Gitea does not cherry pick from Forgejo. They could, the license permits it, and it even permits sublicensing, so it’s not an obstacle for Gitea Cloud or Gitea EE, either. They just don’t.

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.

Better NixOS integration, less resources used, similar levels of containment. The containers I planned to use don’t provide any additional safety than the system services. In many cases, I could harden the system services more. Like, if a container has a /bin/bash in it, it’s hard to remove that, while I can pretty easily prevent my systemd service from accessing it.

Like, systemd.services.<name>.confinement is pretty darn strong. If enabled, NixOS will set up a tmpfs-based chroot with just the required runtime store paths for the service. Good luck doing something similar in a container!

I was in similar shoes (my server is running Debian, as it has been for the past two decades), and am going to rebuild it on something else. I chose NixOS, which I recently switched to on my desktop, because it lets me configure the entire system declaratively, even the containers. The major advantage of a declarative configuration is that it will never be out of date.

My main reason for switching is that I’ve been running the server for a good few years, initially maintained via ansible, but that quickly turned into a hellish bash-in-yaml soup that never quite worked right. So I just made changes directly. And then I forgot why I made a change, or had the same thing copy & pasted all over the place. Today, it’s a colossal mess. With NixOS, I can’t make such a mess, because the entire system is declared in one single place, my configuration.

Like you, I also planned to use containers for most everything, but… I eventually decided not to. There’s basically two things that I will run in a container: Wallabag (because it’s not so well integrated into NixOS at the moment), and my Mastodon instance (which runs glitch-soc, which is considerably easier to deploy via the official containers). The rest will run natively. I’ll be hardening them via systemd’s built-in stuff, which will give me comparable isolation without the overhead of containers. Running things natively helps a lot with declarative configuration too, a nice bonus.

For reference, you can find my (work in progress) server configuration here. It might feel a bit overwhelming at first, because it’s written in a literate programming style using org mode & org roam. I found this structure to work great for me, because my configuration is thoroughly documented, both the whys and hows and whats.

Or one could buy any of the existing pre-built splits. Which might be more expensive, but it does not involve something one very explicitly said they don’t want to do.

I’d rather spend twice as much on a well built keyboard with warranty than trying to solder one together myself and botch it up, and then it suddenly costs more than if I just bought a pre-built one.

I don’t use social media to stay connected with family. I lift up the phone, go visit, or if we need to communicate online, I have an XMPP server for the family with end to end encryption. Can share pictures, text, and can even do video calls if need be, send files, and so on.

Don’t see the need to involve any kind of social media.

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.

There’s a very important difference between what you can do with a thing, and what the thing was intended for, and what it is best at doing.

So then a Game Boy is a PC, and so is the SNES, and the SEGA Genesis. Cool, cool, makes perfect sense.

Myself, I think the wikipedia definition is far better than yours.

Yes, it can run all that. You may have to jump through a few hoops (just like in the case of the Steam Deck, just different hoops), but it can run all that.

I’ll also turn your question back to you: how many people use the Steam Deck for productivity, rather than for gaming, which is its intended purpose? And does it matter?

Like it or not, the steam deck is a gaming console, even if you can run non-game stuff on it too. Heck, even stuff like the Game Boy had (official!) accessories like the Game Boy Camera and Game Boy Printer, which were both useful outside of gaming. Does that stop the Game Boy from being a (retro) gaming console? There’s an ongoing project to provide productivity apps for the Game Boy (though, arguably, it did not ship yet, but you can extend the game boy with a cartridge in whatever way you can imagine).

Or, you can use your SNES as a MIDI Synthesizer (https://www.supermidipak.com/)! No modding or anything necessary, it’s just a regular cartridge. Can it be used for fun? Yes. Is it a game? No. You can do a lot of stuff with an SNES cartridge that has nothing to do with gaming. There was even a cartridge that let you play online games on the SNES (https://en.wikipedia.org/wiki/XBAND) - but not only games, it also let you read and write messages to other people. You didn’t need to go into “desktop mode”, nor install a browser, nor do anything special. You plugged in the cartridge, and it worked. It was far less locked down than the XBox or even the Steam Deck! Does that disqualify the SNES (or the game boy) from being a gaming console?

I disagree. It’s a gaming console. It is marketed as such. It’s primary purpose is to run games. By the way, you can browse on the Xbox. And because it has a full-blown browser, you can even use Office365 if you attach a keyboard and a mouse. So lets disqualify that too? :)

Aren’t all consoles like that, though? They all run mainstream operating systems, and are basically locked down PCs in a fancy box. If anything, the Steam Deck is further from a PC than an XBox/PS, due to being handheld, with an embedded screen and controller, while XBox and its friends require a display and an external controller (like a PC).

Steam Deck, because it is handheld, and can run a lot of my Steam games. I can also dock it to a big screen and attach a controller.