Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SDL Moves to GitHub

discourse.libsdl.org

Post reply on HN
Print view View original

221–230 of 270 posts

Re: SDL Moves to GitHub

#221

Post by moonchild »

josephg wrote: post #215
pjmlp wrote: post #207

Earlier quoted context omitted.

What world? ChromeOS and Android? POSIX APIs are not exposed to app developers. Cloud? Language runtimes and serveless make POSIX irrelevant. IoT? Linux is largely irrelevant in the world of real time OSes and bare metal language runtimes. Desktop? How is that 1% going?

> ChromeOS and Android? POSIX APIs are not exposed to app developers. Cloud? Language runtimes and serveless make POSIX irrelevant. The underlying POSIX filesystem is still exposed to android developers via java's File. And via the C apis too, from the sounds of things. I think its the same on iOS. But even if you're only using posix calls indirectly through complicated database abstractions and unix sockets, you're…

> Aside from performance, in my opinion a better API would also be transactional, at the filesystem level

A better API shouldn't be a filesystem. As a strictly hierarchical system, its only virtue is that it should be easy to create sandboxes and reason about the resultant guarantees. Emphasis on 'should'; in practice, chroots are easy but very ineffective. (I believe fuchsia[0] and plan9[1] do a slightly better job of this.)

Systems based (for example) on tags and tag categories are faster, more expressive, easier to reason about, and can be constructed into arbitrary trees on the fly should the need arise. (They are thus also capable of presenting a hierarchical interface to a legacy application, so compatibility isn't an issue.)

0. https://fuchsia.googlesource.com/docs/+/dart-docs/dotdot.md

1. Because plan9 does a better job than unix of making all resources files, inability to access some subset of files is a stronger guarantee.

Re: SDL Moves to GitHub

#222

Post by iforgotpassword »

dleslie wrote: post #177
fartcannon wrote: post #174

Earlier quoted context omitted.

The only software that actually dies is closed source. And with it, all the money you spent on it. FOSS will outlive us all.

There's plenty of dead FOSS. Anything that relies on a library or build toolchain that's hard to find or configure comes to mind. Go spend some time trying to get RHIDE working, for instance. You're going to have to bring it back to life to do so. And yet, closed source seems to run just fine in emulation.

I really liked the old Presto-based Opera. How useful do you think running an 8 year old browser will be today, emulation or not? ;-)

And the emulation argument can also be made for old open source software, so I don't see how that supports the argument for closed source.

Maybe I just got lucky, but so far I've only ever "lost" CS software, example see above, but never OSS.

Re: SDL Moves to GitHub

#223

Post by pjmlp »

iforgotpassword wrote: post #218
pjmlp wrote: post #189

Earlier quoted context omitted.

Being a bit older this is no different than seeing the 70's hippies generation that helped fighting the dictatorship, working in capitalist right wing companies. Eventually other things in life are more relevant and all that idealism fades away. Even Linux will eventually be replaced by something else, when all the kernel engineers that helped its adoption are gone. It won't be tomorrow, but it will come.

> Even Linux will eventually be replaced by something else, when all the kernel engineers that helped its adoption are gone. I disagree. Linux has reached critical mass, the biggest tech giants depend on it heavily and are the main contributors. If some new fancy subsystem, interface or syscall would benefit Google's workload, they will implement it and it gets merged since even of Google will be the only one using i…

Yes I am talking decades and specifically about Linux, naturally other OSes will eventually share similar fate.

Check Android and maker distributions for how much gets merged upstream.

The only guarantee of the future is that it is unpredictable.

Re: SDL Moves to GitHub

#224

Post by edflsafoiewq »

cpeterso wrote: post #200

What will be SDL's official GitHub repo? The article had no link. Seems like an important item to include. https://github.com/libsdl is an unofficial mirror and github.com/sdl/ is something unrelated.

> We will be migrating on the 10th. Tomorrow.

Presumably you'll know then.

Re: SDL Moves to GitHub

#225

Post by moonchild »

pjmlp wrote: post #219
Jasper_ wrote: post #213

Earlier quoted context omitted.

pjmlp, I don't know how you can keep claiming stuff like this. Android has fopen and pthread and you are allowed to use them in your app.

fopen is part of ISO C, supported by NDK, and pthread is a special case. https://developer.android.com/ndk/guides/stable_apis > Note that on Android, unlike Linux, there are no separate libpthread or librt libraries. That functionality is included directly in libc, which does not need to be explicitly linked against. Better learn how much POSIX Android actually allows.

> pthread is a special case

How's that? It's a posix api among many others which is implemented on android.

How about fork[0], which is one of the more maligned posix apis (as far as I know, no one has any big problems with pthreads). Or errno[1]. Lots of ugly garbage in android...

0. https://android.googlesource.com/platform/bionic/+/refs/head...

1. https://android.googlesource.com/platform/bionic/+/refs/head...

Re: SDL Moves to GitHub

#226

Post by DominikD »

swatson741 wrote: post #18

I've worked on SDL although I haven't contributed any code. Partly because it isn't convenient to contribute and partly because I felt that the work I did wasn't significant enough to merit jumping thru the hoops to contribute. The move to Github is a very welcomed change. > One reason we hadn’t considered a move to GitHub before now is that this project has had a policy of owning all its infrastructure. This is stil…

Found two bugs, reported them, sent patches. It was as easy as it gets. The idea that forking a repo, pushing changes to your own copy, then posting a PR is simpler than posting a diff on a bug tracker is bizarre.

Re: SDL Moves to GitHub

#227

Post by josephg »

pjmlp wrote: post #219
Jasper_ wrote: post #213

Earlier quoted context omitted.

pjmlp, I don't know how you can keep claiming stuff like this. Android has fopen and pthread and you are allowed to use them in your app.

fopen is part of ISO C, supported by NDK, and pthread is a special case. https://developer.android.com/ndk/guides/stable_apis > Note that on Android, unlike Linux, there are no separate libpthread or librt libraries. That functionality is included directly in libc, which does not need to be explicitly linked against. Better learn how much POSIX Android actually allows.

Thats a distinction without a difference.

According to this google result[1] open() / write() are officially part of posix, while fopen() is part of C. Whatever - that distinction misses the forest for the trees. Its the semantics of those methods that hold computing back. Not their syntax.

[1] https://www.mkompf.com/cplus/posixlist.html - I'd have read the spec itself but you have to buy it from IEEE. Blergh.

Re: SDL Moves to GitHub

#228

Post by jhasse »

iforgotpassword wrote: post #104
fileeditview wrote: post #29

Earlier quoted context omitted.

My guess is the network-effect. If you want more contributions Github is the platform to pick for your project. Good or bad it is the de facto standard platform for OSS projects with a huge pool of potential developers.

That's it. Back in the day that's what was great about source forge. Now it's github. Many people already have an account there so you significantly lower the bar for people to get involved with patches, bug reports etc. If a project has self hosted infra and wants me to sign up to their Bugzilla I think twice before doing so. And if github really turns to shit because Microsoft shows their true evil face you can jus…

Check out

https://gitlab.kitware.com/users/sign_in

or

https://gitlab.xiph.org/users/sign_in

You can sign up with your GitHub account.

Re: SDL Moves to GitHub

#229

Post by moonchild »

josephg wrote: post #227
pjmlp wrote: post #219

Earlier quoted context omitted.

fopen is part of ISO C, supported by NDK, and pthread is a special case. https://developer.android.com/ndk/guides/stable_apis > Note that on Android, unlike Linux, there are no separate libpthread or librt libraries. That functionality is included directly in libc, which does not need to be explicitly linked against. Better learn how much POSIX Android actually allows.

Thats a distinction without a difference. According to this google result[1] open() / write() are officially part of posix, while fopen() is part of C. Whatever - that distinction misses the forest for the trees. Its the semantics of those methods that hold computing back. Not their syntax. [1] https://www.mkompf.com/cplus/posixlist.html - I'd have read the spec itself but you have to buy it from IEEE. Blergh.

specification https://pubs.opengroup.org/onlinepubs/9699919799/functions/o...

Re: SDL Moves to GitHub

#230

Post by Deukhoofd »

MaxBarraclough wrote: post #132
rockooooo wrote: post #2

"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…

Depends on the specific software. Plenty of Free and Open Source software 'just works' just about perfectly. Firefox and Notepad++ for instance. In the specific instance of GitHub, I have to agree it's nicer and better polished than the alternatives, but I'd also say the Free Software alternatives (GitLab, SourceHut, etc) are catching up, and are already usable. Hosting your own GitLab instance gives you a far nicer…

I've been running Gitea myself, and honestly I've found it more polished than Github in general. Never really causes me issues either.
Post reply on HN