271–274 of 274 posts
> "At this point, does not yet run macOS application with a GUI" Great, so I can run OS X's shitty versions of Linux utilities... on Linux.
Technically, they are't really OS X's shitty versions of Linux utilities but rather the BSD versions of GNU utilities.
Earlier quoted context omitted.
That's because I (the author) still work on it alone and nobody wants to contribute. I receive tons of e-mails that go like "when will it run XYZ", but practically no pull requests.
You might find the LGPL used by the Wine project to be more attractive to potential contributors. The first thing I thought a few years ago when I read that your project was GPLv3 was that any code that I develop using it would have to be GPLv3. Even if the GPLv3 itself might not force that for "system libraries", the harassment from armchair legal experts would. As much as I like OSS licensing, I do not like having…
I also want to avoid the inception of businesses providing enhanced Darling for money without releasing the full source code (think Cedega), because in my view, that's akin to a fraud committed on other developers who invested considerable time and didn't ask a dime for it.
Earlier quoted context omitted.
People will never stop complaining about look and feel. It's such a crap, it doesn't matter. How much clothes do you own? Computers are tools to do work and consume information, they don't exist for you to make a statement about your aesthetics opinions.
To use your clothing analogy, consider this: what would you think if you bought a button up shirt and the buttons were not spaced equally, they were different sizes and colors, and some were on the right, some on the left. It works just as well as a shirt with standard construction, but it takes longer to put on and maybe it doesn't look very good. There's been a great deal written about how attractive things work be…
Earlier quoted context omitted.
> [...] The manual page for pselect, for example, even admits that it's not compliant! Where does it say that? I'm running 10.12.1, and the man page for pselect(2) looks like the one from FreeBSD. I could believe that pselect doesn't actually behave as documented, having run into my share of macOS bugs. > [...] Porting stuff to macOS is about as painful as porting to Solaris or AIX, which is to say not very painful […
IMPLEMENTATION NOTES The pselect() function is implemented in the C library as a wrapper around select(). That means it's not actually compliant. pselect needs to _atomically_ unblock signals so that if any signal handlers are invoked pselect returns EINTR error. User code can't emulate the correct semantics because there's a race between unblocking (i.e. changing the signal mask), checking for signal arrival, and ca…
Anyway, the man page for pselect(2) in 10.12.1 doesn't have that section, and when I run your test program it prints "OK". So it appears that this particular bug was fixed. It only took them 2 years (could be less if it was fixed in 10.11) this time, which was an improvement over their turnaround for fixing the rename(2) bug[0]. :-P