And people called me crazy for using both codeberg and github
this post was submitted on 14 Aug 2024
-1 points (0.0% liked)
Linux Gaming
14941 readers
271 users here now
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
Resources
WWW:
Discord:
IRC:
Matrix:
Telegram:
founded 1 year ago
MODERATORS
Considering switching to Codeberg. Any tips, advice? Could I sync codeberg and github?
Last time I tried Codeberg, it went down every other day. So if this prompts you to switch, my advice is: don't.
I'm actively using it and have never seen it down.
Which isn't to say, it's never down, I do sometimes see them announcing maintenance windows on Mastodon, but those are certainly not every other day and usually over pretty quickly...
Edit: Last downtime they announced was on the 2nd of August, for a server software upgrade. It was finished in less than 9 minutes: https://social.anoxinon.de/@Codeberg/112894115492565393
So, yeah, I don't know when you tried it, but I do think, it improved massively since then...
This has absolutely nothing to do with Linux gaming.
https://github.com/GloriousEggroll/proton-ge-custom
https://github.com/FeralInteractive/gamemode
https://github.com/derrod/legendary
list goes on
impossible to build a linux gaming computer at this point in time without GitHub
was in the middle of doing so when it went down
With that logic you can connect anything to anything. We can start posting news about war in Ukraine here or something like that, because with enough desire one can find even more indirect connections.
Oh, that ones easy. The developers for Stalker 2 are in Ukraine.
I want to post vegan recipes because I'm a vegan Linux gamer.
and here is more
https://github.com/RusNor/StartWine-Launcher
the Ukraine and Russia situation is definitely a linux gaming thing too
there are coders in Russia that make great proton tools for running games with it without steam and the other day someone was posting about gpu files also on here so though this was in the same vein
intricately linked tetris for fucks sake Russia has been on the nonwindows gaming scene for a while
https://en.wikipedia.org/wiki/Electronika_60
Ahh so this guys either a troll or a conspiracy nut. Ez mute.
It was down a whole 36 minutes. 🙄 I'll worry when a Clownstrike level event happens, this is nothing.
I love how the same people who try to drag me towards using Git are the only people who seem to have serious problems working on their code when a website goes down.
Git is a distributed VCS just like fossil. GitHub never has been an integral part of it; it's just the most popular hosting option. This is like saying you're glad you're using Firefox because everyone complaining that Twitter is down is using Chrome.
Even if you do just GitHub for hosting you can, on account of it being distributed, still work and commit code.
What is more disruptive is that so much code is hosted on GitHub that even if you're not yourself hosting anything there, you risk almost all your dependencies being unavailable to your build pipelines. If you didn't have a cache set up, you're gonna have a bad time.
Too much of their process it's tied in with GitHub. That's what people are complaining about.
Using git (or equivalent) is pretty important. Using github is pretty optional.
It doesn't look so optional to me if I read the tearful reactions on social media correctly. Apparently, an overwhelming majority of Git users ‘can't work’ when GitHub is down.
They're probably not talking about using git, since git is decentralized by nature. You can use git without an Internet connection and then sync everything back up when you have an internet connection again.
Some people literally call GitHub, git and ... they're just wrong.
They also might be talking about review and project management facilities GitHub provides as a service.
It’s relatively easy to self host your own git repositories.
It’s just that Github adds a lot of extra value added features that help streamline things for larger projects, and this is why many people use it. For most people, the value they get far outweighs the inconvenience when it goes down for 10 minutes here or there.
It's still optional, they just chose poorly.
Here's hope they'll learn from this.
Eh you still can, the git remote is a mirror but you can still make commits locally and sync later
Then what's with all these devastated comments on social media?
You're trolling at this point, right? You have a Boxxy profile picture and yet you're confused about the dynamics of social media?
There's a difference between "can't code" and "can't work".
A lot of people use git for version control: super good idea, basically anything else is at best unorthodox, at worst bizarrely stupid.
A lot of people also use github for repository hosting, continuous integration, code review, deployment, packaging, etc, etc. this is more of an opinion thing than a standard practice thing, and there are plenty of other ways to get the same tools, either all in one package or from a variety of different ones, self hosted, in the cloud, or some hybrid in between.
If GitHub goes down, you can make code changes and everything to your hearts content. But you might not be able to run your full integration testing pipeline on it, get a code review, or package your software.
If your local build process pulls packages from GitHub or refreshes a remote repository automatically, it can also powerfully mess that up, but that's nothing to do with git. You can use "ctrl-c/v" backups and still have a build process that tips over when GitHub goes down.
Under which circumstances would using any VCS that isn’t Git be “bizarrely stupid” and why? I mean, everyone has strong opinions about something, but I’m curious now.
File1, file2, file_3.new, etc would be bizarrely stupid. A home rolled solution involving rsync, tar, gzip, crons or inotify would also be bizarrely stupid.
https://en.wikipedia.org/wiki/List_of_version-control_software anything on that list that's marked anything other than "active" as a more serious answer. So like DCVS, visual source safe, or bitkeeper. Anything that's not getting bug fixes or maintenance.
Anything that doesn't have significant enough usage to give confidence that bugs or glitches are being caught by common usage would be risky, since you don't want to be the person to find that edge case.
There's things other than git that aren't wrong, but I see little compelling reason not to use the most ubiquitous tool.
Ubiquity is not always the most relevant decision. (Especially as most VCS which aren’t Git :-) are easy enough to understand - most of them are even easier than Git in my opinion.)
Of course it's not the only factor, but all things being equal, the most prevalent tool should be preferred.
It depends on the outer circumstances, I think. Using the prevalent tool makes sense in existing environments (which is one of the reasons why many companies use SVN - it worked for them before Git existed and it still works for them, so why not?). For new projects, one-man teams and/or companies starting from scratch, Git might not always be the best choice.
people like to make a fuss and get attention on social media, it's something to talk about, entertainment
they're weren't even down for that long
Which VCS do you use?
Fossil, mostly, with some Darcs and SCCS thrown in the mix. Some of my older stuff still resides on SVN (and is perfectly reachable right now).
I think I only have one project on GitHub that's not only a mirror. This incident reminds me that this was meant to be a temporary solution.
How do you even know darcs
The internet spoiled me.
Why?
How does fossil or svn protect you from a remote server going down making it's contents unavailable?
Are those advantages worth others not knowing how, or caring to bother, to access or contribute to your software?
What are you gaining by eschewing what is effectively the standard tool?
"The standard tool" is not a constant. When I started programming with other people, CVS was "the standard tool".
There is also the following consideration: Most VCSs work very similarly. It makes no difference to anyone I can think of which VCS they should use. Why would someone who can write "git pull" suddenly despair of (for example) "fossil update"?
Git also has numerous disadvantages for me, including the improvable merging, the contradictory command line commands, the cluttering of the .git folder with numerous metafiles and so on. What's wrong with using the best tool for the job and not the one that "everyone uses"? The supposed advantage that everyone already knows Git (haha, who really "knows" Git?) is outweighed by its disadvantages in my opinion.
Fossil, to stick with this example, also has some advantages for me as an administrator: Each repository is a single SQLite file (easy to backup, easy to repair, easy to host - without complicated infrastructure, a web server is enough).
We very clearly work in different professional environments. :)
In no particular order: Administrating a git server is similarly trivial. A repository is a folder (easy to backup, easy to repair, easy to host), and setting up a new server usually a matter of ssh key management. Don't even need to install sqlite or anything beyond the git package. Or, because the tool has wide support, you can install a wide selection of tools that manage it for you, or use a free hosting service, or a paid one.
I'm startled that you would say you can't think of anyone who would care. My entire professional experience has been developer stories about bad jobs often include details about using old or esoteric VCS systems, usually met with "ew" or "wtf" comments. Sets the flavor of the story.
Personally, in a business environment, I would take using anything except git for the org as a red flag. It's a sign that someone in leadership at the company values doing things unrelated to the core mission "their way" above doing it the easy or "paved path" way.
The standard tool is indeed not constant. Before git existed, using CVS would have been the better choice, as well as for years afterwards until it had clearly been usurped. Most projects aren't Linux when it made the switch to git.
You joke that no one really "knows" git, but... This is literally the first time I've ever seen a fossil command. I just searched for "fossil manual" and I get analog watches. It's not even available in any of my systems package managers.
Developer familiarity is a big advantage that I think you're downplaying in comparison to "there are metadata files in .git", which I don't know has ever been relevant to me in any significant way.
(Also, I thought the different systems all work basically the same? 😛)
I'd handily agree people should be using the best tool for the job. Familiarity and ease of use are significant factors in what makes a tool better.
Ability to integrate with other tools is also a major factor. Setting up continuous integration or code review tools with git is trivial with any number of different systems.
What are any of the tools you're using doing better than git? The biggest selling point you've shared for fossil is that it's functionally similar to git, and that it has better merging. I can't find anything related to merge conflicts outside of years old forum posts, and barely anything relating to merges at all, so I'm not entirely certain what makes it "better".
If it's biggest advantage is that it's similar enough to git that you can pick it up fast, why wouldn't I just use git?
You don’t need to install SQLite to use Fossil, as Fossil already contains the (newest) version of SQLite, given that both tools come from the same developer.
In my experience, Git is harder to use than Fossil and if shit hits the fan, it is much harder to unshit the fan. There are reasons why there are numerous tutorials and books about how to tame Git. I don’t want to have to tame the tools that I use every day.
And yes, most tools are not Linux. Linux is a huge bazaar (with one BFDL, but that’s optional). Most real-life projects are a cathedral though, and Git just doesn’t mirror this.
I'm not sure I'd construe a manual you can find, or a variety of guides, as a negative. :) most days my usage of git consists of "pull, commit, push, merge" in different orders. You might be overestimating how much effort goes in to managing the tool.
Most of my professional experience has been working on projects that consist of multiple teams of between 4-6 developers, and between 5 and 40 teams. I'm not entirely sure what you mean about git not mirroring the development patterns of most "real life" projects.
"Real" projects are frequently developed by groups of people working on the same goal adjacent to other groups working on related but distinct goals.
Most groups of people who write code have one person to report to.
I took a look at the Fossil website and still don't get this: how do remotes work, and how would Fossil's version of remotes prevent the main server outage from stopping global VCS collaboration? I'm sure there's a good answer but I can't find it from the website.
It doesn't.