Live data from Hacker News

SDL Moves to GitHub

discourse.libsdl.org

151–160 of 270 posts

Re: SDL Moves to GitHub

#151
post #3

I've never heard of mercurial until this post, I've been using git for version control and it does the job really well. To those who use mercurial over git, why?

Because I can explain Mercurial's mental model to anybody. And I have--from the CEO to the secretary--pretty much anybody can understand Mercurial.

Git, not so much. The whole "staging" area is something that the vast majority of developers simply do not need and would be better off without. The UX of the commands is abysmal--commands that change what they do based upon whether the argument is a file or a directory? Are you insane?

I could go on and on and on ...

However, git has won. I keep my repos in Mercurial and transfer them out to Git for public consumption. :(

Re: SDL Moves to GitHub

#152

Earlier quoted context omitted.

A much better UI. Git won because of the influence of the Linux kernel developers, that's all.

If I remember correctly Mercurial also made some dubious decisions early on (which they later reversed) that hurt adoption, like no in-repo branches and no ability to change history.

Mercurial also made the really good decision to support Windows long before git was even functional there. I've got clients who have been using Mercurial on Windows for more than 10 years now. They email bundles to each other and have no problems, whatsoever, and don't even notice git. One quote: "Why would I want to go back to a central repository that I have to be connected to? That's stupid."

Most Windows users, sadly, are simply too backward to use anything that isn't tightly integrated into the Microsoft ecosystem. So, it never really helped Mercurial that much.

GitHub, however, was what drove git.

Unfortunately, Github is to source control as PowerPoint is to presentations. It works--but it's a dumbed-down default and nobody thinks about the fact that there are sometimes much better alternatives for your use case.

Re: SDL Moves to GitHub

#153
post #57

Earlier quoted context omitted.

Personally I find this far more worrisome signal of the health of foss ecosystem than the quibbles between elastic and amazon. To me the idea of software "by hackers for hackers" and scratching your own itch has always been one of the key attractions in FOSS ecosystem, but somehow now our itches seem to have outgrown our ability to scratch then. Doing almost anything yourself feels impractical these days. This is als…

For better or for worse, this is nothing new. It is a symptom of the fact that the FSF and other FOSS organizations have displayed a fantastic failure of technical leadership for over 3 decades. The political leadership has not been bad, but if you go back and dig through the history of open source you will see that there have been multiple repeated failures by the supposed thought leaders to provide the equivalent l…

FWIW Stallman's stance was always that freedom is more important than technical excellence and that he'd rather use and promote a technically inferior product that respected users' freedoms than one that was technically superior but came with shackles.

Re: SDL Moves to GitHub

#154
post #101
post #55

Earlier quoted context omitted.

Since the Microsoft takeover, the platform is compromised. It seems people have very short memories.

Microsoft is a completely different company than it was even just 5 or 10 years ago. Saying that MS is an enemy of open source is uninformed at best and idiotic at worse. Do me a favor, look at Facebook [1], Apple [2], Amazon [3], Netflix [4] and Google [5]. Now tell me which one has more Open Source repos than MS [6]. I'll give you a hint... none of them. Sure, volume of open source repos may not be the best metric,…

> Microsoft is a completely different company than it was even just 5 or 10 years ago. Saying that MS is an enemy of open source is uninformed at best and idiotic at worse.

Rather than fighting the target directly, they are embracing it at first; and this time, the target is open-source and the developers. They are doing it again and are targeting where the developers are: Hence their involvement with GitHub, Xamarin, Linux Foundation, Chromium (MS Edge), WSL 2, VS Code, TypeScript and Azure and it is working for them.

The company has not changed. Only the target has, and they are already embracing them and slightly started to extend.

Re: SDL Moves to GitHub

#155

Earlier quoted context omitted.

For better or for worse, this is nothing new. It is a symptom of the fact that the FSF and other FOSS organizations have displayed a fantastic failure of technical leadership for over 3 decades. The political leadership has not been bad, but if you go back and dig through the history of open source you will see that there have been multiple repeated failures by the supposed thought leaders to provide the equivalent l…

FWIW Stallman's stance was always that freedom is more important than technical excellence and that he'd rather use and promote a technically inferior product that respected users' freedoms than one that was technically superior but came with shackles.

Which is one of the reason's Stallman's ideas are fundamentally flawed as if there's a better product available even if it's only free as in beer, people will use it over the worse one, from the end user's perspective.

Re: SDL Moves to GitHub

#156

"So in moving it to GitHub, we’re finding that a lot of things are just nicer because a large paid staff of engineers is working on it every day. And I grew up during the heydey of the Free Software Foundation, so I know this is a trap, but I’m tired and don’t have the energy to be a server admin for something that’s held together with scotch tape and prayers when I’m really supposed to be writing OpenGL code." This…

Wonder why they did not pick GitLab since it is significantly better for FOSS ideals and has the same niceness of GitHub

Sorry but GitLab is utterly horrendous from a developer's perspective compared to GitHub. It's massive enterprise bloatware (like most Atlassian products for example) that is nigh unusable without an entire team of people to manage it. My company uses it and it causes me problems almost every other day. Things that should "just work" never do.

Further when something gets reported to GitLab they automatically close old issues and things never get fixed. One outstanding huge issue is that if you mark certain files as owned by a specific team for example, it won't notify the teams to come in and actually review the code. There's options that say they do it, but it never works. (The notification system in general is an utter mess.)

GitLab is an example where everything is chopped up into tiny pieces and nothing works across different parts of the codebase. I don't envy anyone that works for GitLab as just the look of the code shows what a mess the backend must be.

Re: SDL Moves to GitHub

#157

Earlier quoted context omitted.

Just be aware that "boomer rant" creator made one of the most highly successful and used game development libraries in history. I would wager 75% of the games in your steam library use or depend on SDL in some way. Almost certainly most of the games from your childhood that you cherish and love have used SDL too. You should probably be thanking them for creating something that gave you joy at one time, and giving it…

I see where the SDL author is coming from, but is it really that hard to get local GitLab instance running? Or even just using GitLab? I saw other replies about how GitHub has a network of open source developers, but that didn't bother the SDL author before, and I don't see why it is bothering him now.

You missed a key point that the SDL author raised--they're tired of maintaining all the ancillary software around a project. Every minute they waste troubleshooting a CI/CD failure, bugzilla limitation, etc. is a minute taken away from working on their actual project. And as this is an OSS project of love and not their full-time job it's even more infuriating for them to waste their free time janitoring services.

Gitlab self hosted is fantastic, but it's far from 'set it and forget it' maintenance. There's significant technical overhead to keeping it updated, secure, migrating its database with major releases, scaling out the underlying hardware as project demands increase, etc. Moving to a hosted platform like Github solves those problems and gets them back to being productive on their project.

The authors are really lamenting that they have to give up control of their project's source code and tie themselves to a new commercial offering (something that history has shown us over and over will inevitably lead to more technical debt in the future as platforms fade--just ask any former sourceforge, google code, etc. user).

I don't blame them--it's sad to see that the state the art in self-managed OSS source code never progressed much beyond "become a domain expert in server operations and kludge together a suite of tools with wildly different UI, management and operations; also, documentation is non-existent or wildly out of date".

Re: SDL Moves to GitHub

#158
post #149

It seems libsdl2 does not support framebuffer anymore, which is critical for embedded devices(no gpu or 3D acceleration i.e. opengl needed there)

Yeah, libsdl2 is built around more modern rendering devices and drawing APIs, and supports far fewer (but more popularly used) platforms. And is vastly faster on those platforms than SDL1.2 used to be, since it’s playing to the strengths of those modern devices, instead of fighting against them the way that SDL1.2 did.

Do note that libsdl2 can emulate framebuffer-style “I just want to splat pixels to the screen”-style program architectures just fine using “streaming” textures [0], but that’s not going to help you if it doesn’t support your platform.

If you need broader platform support and/or are running on low-power devices, then libsdl1.2 is still around and supported, and is probably a more appropriate choice for such projects.

[0]: http://wiki.libsdl.org/MigrationGuide#If_your_game_just_want...

Re: SDL Moves to GitHub

#159
post #139
post #36

Earlier quoted context omitted.

> To create a new commit in git you need to run `git add` followed by `git commit`. Or `git commit -a` — and if you're making commits that frequently it'll be in your shell history anyway.

Except that if you added a new file then "git commit -a" will miss it out. Git's UI is full of little sharp edges like that. You get used to them, but it's just needlessly fiddly to start with.

> Except that if you added a new file then "git commit -a" will miss it out.

Exactly like Mercurial, you mean? Try it if you haven't in a while: you have to call “hg add” to add a new file or you'll get “nothing changed” when you run "hg commit".

The reason why neither of them has a default “add everything in the current directory” mode is that this is how you end up with repositories containing temporary files, build artifacts, and secrets.

This is not a good example to base ”much better UI” claims on.

Re: SDL Moves to GitHub

#160

Earlier quoted context omitted.

I just wish they would invest in the code review aspect of their tools. It’s pretty trash compared to competitors like reviewboard or phabricator (haven’t used Jira or Gitlab recently so can’t comment on those). A big missing feature is the ability to easily upload a stacked diff. Also the whole pull request thing is confusing - why not just use the commit and automatically populate title/summary + figure out which b…

at least on Github, if your branch only has one commit, it will use the commit to automatically populate title and summary. And recently pushed commits show up on top of the repo page with a one-click button to open a PR :) (or you can go to the "branches" page to do this as well)

It does not prepopulate in my experience (or if it does, not reliably). And I literally said I want an easy hit command line way to just push to a special branch name to have the pull created.

You’re answer is the stereotypical answer of telling the user to adapt to the tools instead of improving the UX (not to mention completely ignoring my point that GitHub doesn’t support stacked diffs). GitHub has a lot of advantages and has maintained their community but they lack pretty badly in some ways on the usability of their UX flow/feature set for power users. This isn’t necessarily accidental or a wrong decision since they might be prioritizing the broader dev community that isn’t familiar with more opinionated dev workflows and they’re solving the Ux for 90% of PRs. I still think there’s a way to strike that balance better and I hope they do so so that I don’t hate my life whenever I’m forced to use GitHub.

Post reply on HN