Live data from Hacker News

SDL Moves to GitHub

discourse.libsdl.org

241–250 of 270 posts

Re: SDL Moves to GitHub

#241
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.

No it does not, a platform with ISO compliant C compiler is not required to support POSIX in any form.

By the way, since C11, there is no need for POSIX threads any longer.

C11 threads might be implemented on top of POSIX threads, or anything else that the compiler vendor thinks of.

Re: SDL Moves to GitHub

#242
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.

> 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...

So what?

APIs that aren't part of NDK stable API contract are not allowed, and since Android 7 Google has started to implement security measures to kill processes that try to use private APIs, one of the reasons why termux is no longer.

Good luck using your beloved POSIX APIs and not being killed in random Android devices.

Re: SDL Moves to GitHub

#243
post #223

Earlier quoted context omitted.

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.

> The only guarantee of the future is that it is unpredictable. Yet here you are making predictions... I doubt Linux will fade away until there is some major paradigm change away from Van Neumann architecture. It has survived and become dominant over 30 years by constantly adapting and innovating.

The plethora of IoT FOSS OSes with MIT/BSD licenses already show where the train is going.

Re: SDL Moves to GitHub

#244
post #90

Earlier quoted context omitted.

git was the clear winner when github released.

Not really, lots of folks were using mercurial with BitBucket which didn't support Git at the time. Bazaar and Launchpad were also pretty common. I remember at one point around 2009-2010 I was semi-regularly using CVS, Subversion, Mercurial, Bazaar and Git.

lots of people were using lots of things at that time, most were using git.

Re: SDL Moves to GitHub

#245

Earlier quoted context omitted.

Sure, but I'd have a tough time finding proprietary software that I'd want to use that isn't adequately emulated. As for updating, well, I'm not going to be updating most FOSS, either. Right now I can double-click an icon on my desktop that launches SimCity for Windows 3.1 inside of dosbox, and it works great. It didn't take much effort to get working, either. I can't say the same for most dead FOSS that I've tried t…

Sure, you're obviously a popular person and your friends/family are always more important than updating software. But if you wanted to, you _can_ update dead Foss. Can't update that copy of Simcity, can you. Nopers.

Not quite, there are ways. The Diablo mod community is an excellent example: before the debug symbols were found on the psx release, the common method was to inject instructions directly into the binary. Similarly, Fallout and the Infinity engine games have mods that patch binaries and replace DLLs.

Re: SDL Moves to GitHub

#246

Earlier quoted context omitted.

> 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. I agree that many FSF/GNU projects have made horrible technical choices, but I don’t think that’s really the root cause here. The reality is that good software requires an enormous amount of skilled labor to create and maintain, and the FSF and other OSS orgs can only…

And of course, no closed software has _ever_ had a poor UI/UX.

I don't think anyone claimed that. Do you disagree that OSS tends to have a worse UI than commercially developed software? If not, what's your point?

Re: SDL Moves to GitHub

#247
post #32
post #9

Earlier quoted context omitted.

> A much better UI Curious as how it's "better". I have in all honestly only ever used git.

One thing I prefer about Mercurial is that it doesn't have a separate staging area. To create a new commit in git you need to run `git add` followed by `git commit`. In Mercurial it's just `hg commit`. Furthermore, if you want to look at the diff in git sometimes it's `git diff` and sometimes you need to run `git diff --cached`. Now, I'm sure there are antsy git users in this forum ready to reply about how great the…

So everything that you modified since last commit will get committed regardless? I can't add logging to some file or manually override a config without it getting it committed as there is no staging? Doesn't sound like much of a selling point, unless I'm misunderstanding...

Re: SDL Moves to GitHub

#248

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…

> 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. I agree that many FSF/GNU projects have made horrible technical choices, but I don’t think that’s really the root cause here. The reality is that good software requires an enormous amount of skilled labor to create and maintain, and the FSF and other OSS orgs can only…

>Even if someone did want to help in this role, the developers on most projects would probably ignore them.

This is the lion's share of the problem, I suspect. OSS projects are driven by the people who write the code, and they don't take orders, and they don't massively value making things easy to use - or even necessarily have much connection with what that means. Current computing is such a pain in the ass that we've basically selected for inhuman levels of persistence and patience, and placed a large cultural value on those traits to boot. "Read the docs", we say. "Use the source", we say.

We don't have any idea how many human factors experts are out there, willing to help, because there's no process for them to contribute beyond "submit a pull request" - and even then, a purely UI tweak will meet with huge resistance. The UI expert is going to have to be a diplomat as well.

Re: SDL Moves to GitHub

#249

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…

> 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. I agree that many FSF/GNU projects have made horrible technical choices, but I don’t think that’s really the root cause here. The reality is that good software requires an enormous amount of skilled labor to create and maintain, and the FSF and other OSS orgs can only…

Stallman and by extension the FSF are opposed to user experiences. He links to the following article on his website:

http://contemporary-home-computing.org/RUE/

Re: SDL Moves to GitHub

#250

Earlier quoted context omitted.

Sure, you're obviously a popular person and your friends/family are always more important than updating software. But if you wanted to, you _can_ update dead Foss. Can't update that copy of Simcity, can you. Nopers.

Not quite, there are ways. The Diablo mod community is an excellent example: before the debug symbols were found on the psx release, the common method was to inject instructions directly into the binary. Similarly, Fallout and the Infinity engine games have mods that patch binaries and replace DLLs.

Yes, that's right, certainly easier than having the source. Your friends and family must appreciate the time you saved them by injecting DLLS. You'd better hope you efforts don't get DMCA'd.

Summarizing, closed source projects die. At best you can run them in an elaborate museum (emulator) and at worse, you can attempt to Frankenstein's monster them by injecting DLLs.

Open source will outlive us all.

How many places does Doom run?

Post reply on HN