Any evidence of that? Genuinely curious as I can’t really find anything about them being by the same people and forgefed started as mailed-based prior to forgejo existing.

edit: seems like they are funded by different organizations and the main contributors to forgefed never worked on forgejo, they worked on vervis though.

Just to give credit where credit is due, git federation is a Forgefed Initiative

Forgejo is implementing it in their platform.

One of the first interaction I witnessed from the forgejo guys was this PR:

https://github.com/go-gitea/gitea/pull/27455/

The interaction and stubbornness of earl-warren felt like it was just that, provoked drama.

I use owncloud infinite scale and overall its rock solid. The downside is the lack of plugins. Nextcloud has been nothing but trouble for me and every update was a mess so I decided to try OCIS and for my need I was extremely satisfied.

Now, I admit, I’m not one to get carried by the drama in the FOSS sphere (still use Gitea) but I do agree there is an history to the separation of owncloud and nextcloud that can make some people uncomfortable. Having a choice is good I believe.

There you go:

# Start an infinite loop because True will always be True
while True: 
    # try to run the main function, usually where everything happens
    try:
        main()
    # in the case an exception is raised in the main function simply discard (pass) and restart the loop
    except:
        pass

For those curious about the drama & lack of wide adoption surrounding the walrus operator

https://dev.to/renegadecoder94/the-controversy-behind-the-walrus-operator-in-python-4k4e

It’s a shame because it’s a really nice feature.

I started using hatch lately and really like how I can manage everything from the pyproject.toml file

https://github.com/pypa/hatch

My secret to high uptime:

while True:
    try:
        main()
    except:
        pass

Edit: something that are not arm based

You want pre-built to run ollama, that’s at least gonna cost you an arm, maybe even a leg.

I know the language is really academics focused and is really strong in that sense. Otherwise I found that it was a great language for long running services. I use it for some APIs and algorithm trading bots.

I’m debating putting more hours into it, maybe trying a website in genie, but I agree the current ecosystem makes it a hard sell when I can use python instead.

Or, hear me out, .step files. It’s an ISO standard so you know it should be the same across all 3D modeling softwares with lots of support.

I don’t know if no one mentioned Julia because it’s considered popular enough or because it’s really not popular but… Julia for sure.

One of the most known programming tool is built on Ruby, Github.

Forgejo contains all of Gitea, and that has the benefit of allowing Forgejo to be a drop-in replacement. With the decision to become a hard fork, this will no longer be guaranteed

I’m glad to see them move their own direction but I’m skeptical considering the amount of commits they take directly from Gitea. I could see this becoming more like a Fedora/Rhel type of fork but we’ll see.

I’m personally staying with Gitea for now as I have yet to find a reason to switch.

I’ll say that as someone who stopped using docker and went back to deploying from source in lxc containers: dockers is a great tool for the majority of people and that is exactly what it aims to be, easily reusable in as many different setups as possible.

On the flip side, yes it may happen that you would not benefit from docker for a reason or another. I don’t, in my case docker only adds another layer over my already containerized setup and many of the services I deploy are already built from source in a CI/CD workflow and deployed through ansible.

I do have other issues with docker but those are usually less with the tool and more with how some project use docker as a mean to replace proper deployment documentations.

If I’m updating the source code already I might as well build my service from it, I really don’t see how building a docker container afterward makes it easier considering the update can also break compatibility with the docker environment.

Also adapting can be a pita when the package is built around a really specific environment. Like if I see that the dockerfile installs a MySQL database can I instead connect it to my PostgreSQL database or is it completely not compatible? That’s not really something the dockerfile would tell me.

I have a love/hate relationship with docker. On one side it’s convenient to have a single line start for your services. On the other side as a self-hoster it made some developers rely only on docker meaning that deploying the stack from source is just an undocumented mess.

Also following the log4j vulnerability I tend to prioritize building from source as some docker package were updated far later than the source code was.

The majority of maintainers stayed with Gitea. Forgejo is not the tip, they still pull the majority of their commit from gitea directly.

Oh now you’ve gone and jinxed it.