(Edited for typos)
Now I see that Gitea is the software (basically a clone of GitHub that is visually almost div-for-div, released with an MIT license, that you can host yourself), and Codeberg is central hosting (a "hub") running Gitea, operated as a non-profit.
Gogs is still in development as well. If people are interested, definitely check that out as well.
Gitea is very slow (eg 4s GET requests) for large codebases. cgit is like lightning.
To me that would be the most important differentiator. Do any of the others do it?
A simple way to represent it might be as an ASCII dump of one or more databases representing it all, so you could roll back to any day's state; or as an update-log transcript, so you could roll back to the state after any given transaction. Both amount to successive diffs, so are reasonably compact.
Except PRs, bug reports etc. can't affect the runtime behavior of your program, only code can. There are many times when I am looking through a dependency's history to see "what changed?" in order to decide if I want to pull a new version, and the ONLY thing I want to look at in that case are code changes.
> Furthermore, why should PRs, bug reports, and build artifacts not be able to refer directly to source objects and revisions, and vice versa?
I do that all the time in GitHub today.
I certainly understand wanting that auxiliary data to be versioned, and I also understand wanting it to be in a portable, distributed format like Git. I just definitely don't want it cluttering up the history of my code
Also, security is a big deal. I often want to allow pretty much anyone to open a PR or an issue, but I don't necessarily want that now to be part of the repo every time someone clones it.
Are your repos free of docs, READMEs and tests, then?
> I just definitely don't want it cluttering up the history of my code
> I often want to allow pretty much anyone to open a PR or an issue, but I don't necessarily want that now to be part of the repo every time someone clones it.
That is a good point; perhaps solvable by having the webapp frontend provide the GUI but make commits itself? That should give you the best of both worlds.
Here are the tables on my at home deployment:
mysql> show tables
| Tables_in_gogs |
| action |
| attachment |
| collaboration |
| comment |
| commit_status |
| deleted_branch |
| issue |
| issue_assignees |
| issue_user |
| milestone |
| mirror |
| notice |
| notification |
| oauth2_application |
| org_user |
| protect_branch |
| public_key |
| pull_request |
| release |
| repo_indexer_status |
| repository |
| review |
| star |
| stopwatch |
| task |
| team |
| topic |
| tracked_time |
| update_task |
| upload |
| user |
| watch |
| webhook |
| [...] |
67 rows in set (0.01 sec)
So many people seem to think that providing low quality translations is improving accessibility. It isn't. It's doing the opposite, pure english websites provide much better UX to international users.
BTW, Microsoft with their automatically translated MSDN docs is by far the worst offender in this area.
By all means, advocate for making it easy to change the language back to the original. But this stance will decrease accessibility.
You don't, plenty of developers are getting around having to know English as there are other resources for learning.
I think it's a dangerous assumption that everyone knows English. It's especially true in the Spanish-speaking world, where I know developers who can't have a conversation in English but are good enough to be employable.
For example, take their Swedish translation of “pull request”: “Pull-förfrågning”. They had to leave “pull” untranslated, probably because it would be impossible to understand if you actually were to translate it word by word; unfortunately “pulla” is a sexual slang word in Swedish , so the whole translation sounds like a request for sexual assistance.
Table shows that "pull" is usually referred to as "pulla" but the suggestion is to change it to "rycka". If you do know Swedish, there is a discussion about the naming of "pull" here: https://github.com/bjorne/git-pa-svenska/issues/30
In Sweden, you can assume that pretty much everyone understands English, so if your website has an incomplete Swedish translation, might just be better to go with English one anyways.
But in Spain (outside the big cities), not that many people do understand English. In that case, it'll be better to serve a incomplete Spanish version instead of in English, as otherwise they'll be completely lost.
So as always, I'd say it really depends, and it's hard to generalize over all "international users".
I'm a native English speaker, so I don't know.
France has an obsession about its language (which is wonderful) and believes that the whole world should adapt (which is dumb in tech). You should attend some union meetings where all docs are expected to be in French "because that's the law". The reality of the world is not a concern of theirs.
Source: I am French, work in tech and see how much this illusion of "everything in French" hurts us.
If you do not speak English then either learn, or work outside dev.
You wouldn't be able to have a software design session in English, but they would understand specific English words and even use them when speaking Spanish generally.
Good to know
You can switch language quite easily using the menu in the bottom center/right.
Also, in a self hosted context you can disable/enable languages in the configuration file easily.
Also, if you find the translation really bad (I think in most cases, the default translation is from MS automatic translation), you cam easily contribute to it:
I personally contributed to the French translation a few years ago, which was really bad in Gogs at the time, specially with some over translation of technical terms such as "git commit" which was translated to "git commission" (a bit weird and laughable since "faire une commission" can be a weird formal way to say "pooping" in some contexts).
I took me a few hours to go through a few of the message strings and propose an hopefully better translation. It's quite easy to contribute to the project in this manner, far easier than contributing code.
Lastly keep in mind that gogs was created by a Chinese developer, and I'm half expecting that Chinese developers are not as fluent in English as developers from India or Europe. In this context, pushing for an internationalized service is a good call vs an English only UI.
Not translating isn't really a solution.
Wanting everything to be 100% translated is also unrealistic.
E.g. looking at the quality of Microsoft's German translations (which seem to be done by a poorly trained bot), the translation is actually counterproductive, because it's full of special terms translated into German that either would not be translated from English in a "native" German text, or where a different translation is commonly used.
My favourite is the Visual Studio translation for Link-Time Code-Generation. Which is translated as "Link-Zeitcode Generierung" which in English means "Link Timecode Generation".
In other countries like Russia or Japan I noticed, as an outside observer, more reliance on translations.
When translating a complication is the degree to which one does it. There are terms which can be translated and some where it becomes weird. In some parallel comment "pull request" was mentioned. Translating that certainly becomes weird, but translating "file" as "Datei" is well established and - when translating - expected.
I do agree that it’s not a walk in the park because it takes loads of resources to provide actual translations and one has to make i18n a feature in the code. But... come on. phpMyAdmin was doing this in 2004.
However finding the right translation level in technical context is hard. For which concepts should one translate the name and which terms should one borrow the English term? The French translate "computer" as "ordinateur", the German "Rechner"/"Rechenmaschine" however is outdated.
Now what about a git repository clone and commit? How much translation will destroy understanding?
Unfortunately that's misunderstanding that fundamentally language relies on way more context than just strings to get the same message across.
You can't just simply translate and have a good UX for other languages.
This is a nice summary: https://blog.codeberg.org/codebergorg-launched.html
Suggestions on how to make the messaging of Codebeberg clearer would be appreciated, Codeberg has an issue about this in their tracker: https://codeberg.org/Codeberg/Community/issues/75
Edit: added link to Codeberg issue tracker
But is it? Where can you find the code for codeberg itself? Is it possible to download it all and install it locally on an air-gapped server?
They have a repo with the patches that are used on on codeberg.
Sourcehut is specifically designed to be a composeable set of services, so regardless of language, it's never going to be one binary.
Hm, monolith != unscaleable monolith. Monolith just means you'd have to do vertical scaling instead of horizontal scaling, which arguably is easier and less error prone, as you still are only dealing with one instance and not building a distributed system all of sudden.
I usually try to keep to vertical scaling for as long as possible, until either the performance starts to plateau or the product/project becomes big enough that it needs different backend dev teams working on different things concurrently.
Thee reason for this is that writing anything at all to be scalable is quite difficult, and larger monoliths tends to reflect a laziness and false sense of simplicity that tends to also be reflected by the internal design. For this reason, I'd consider "large but scalable monoliths" to be in the minority.
Furthermore, I'd argue that if scaling of a monolith isn't a problem, it's simply because its load is insignificant in the first place. Once the scaling game starts, vertical scaling quickly ends up being infeasible.
Of course, that does mean that you can start out and experiment with a monolith while a product is young, but I'd prefer to have hashed out the overall design before I start dealing with production systems.
I'd design components around clearly distinctive areas of functionality rather than the distinctive teams that need to write it.
No imprint, no privacy statement, no deal.
Imprints on websites are only required in a few countries. Frankly, I find it absurd that on the one hand, my contact details as a domain owner are being removed from WHOIS citing data protection, but on the other hand I am required by law to put the same information on the website I'm running on the domain.
I am not going to pay money to some organization when I don't even know who that is and where they are located.
Sourcehut as a company is designed to make the relationship between you and the company clear: You are the paying customer, and funding the services. There is no secret agenda or external investor whose interests they must please. Plus, it's the most transparent company I know of.
While you could just ask your questions in #sr.ht, you can also read the financial report (https://sourcehut.org/blog/2020-01-13-sourcehut-q4-2019-fina...) and see what colos they are paying for. At the time, hosting was in San Fransisco and Philadelphia. You can also use their Prometheus instance to check how things are running if you'd like (https://metrics.sr.ht/graph). Both guys in the company's face can be seen and profile read here (https://sourcehut.org/consultancy/).
I don't think your questions can be answered to the same degree from other hosting providers, despite imprints.
I'd love to be able to use my own image, though, I feel bad everytime my build script has to use 3 minutes of build server slot time to download and install a bunch of packages before it actually builds my project, if I could make a custom docker image to build in, or there was caching, it would use less time.
Collaboration platforms like SourceForge, GitHub, and GitLab enabled and facilitated the development and organization of free software projects.
But as developers of free software we fell into a trap – we poured invaluable source code, documentation and last not least a huge and steady stream of data about our personalities, interests and social networks into proprietary platforms.
These platforms are no charities, they operate to fulfill the commercial objectives of their founders and owners, outside of our control. They are valued and sold for billions of dollars.
Codeberg is trying to fix that. The nonprofit Codeberg e.V. has been founded as independent non-government organization to launch and build a free home for Free and Open Source Software.
Also see this short SFSCon talk:
(side note: those slides are amazing lol)
What does this mean/imply exactly?
"Codeberg is a non-profit organisation dedicated to build and maintain supporting infrastructure for the creation, collection, dissemination, and archiving of Free and Open Source Software. If you have questions, suggestions or comments, please do not hesitate to contact us at email@example.com."
It's a kind of club ("eingetragener Verein" ) that is funded by its members and through donations.
To me, not being able to divine the people behind the I iniative is a bit incongruous to being a community effort. Makes it feel like a company, not a club.
Edit: And its not just about resumes, its the case for getting traction for your project too. I feel comfortable contributing to a project hosted on github and am sort of weary of things hosted on other places.
Gitlab is a good alternative, but why not have more choices? Anybody who might want to hire you can click a link to a Codeberg/Gitea site and see what looks like a very familiar repo. It should be the project itself that is attracting users and devs, not where the git repo is remotely hosted.
For free-software projects, a Gitea site like Codeberg might be an even better choice because of the conflicts involved in using a commercial entity like GitHub that uses closed-source software yet bases its entire business on a free project (Git).
Simply put, you are not the kind of user they want. Happily there are alternatives. I started backing up private repos to SourceHut.
Gitea can run locally.
Some functionality is lacking compared to GitHub, but it does what it needs to do for me.