Live data from Hacker News

Darling – MacOS translation layer for Linux

darlinghq.org

261–270 of 274 posts

Re: Darling – MacOS translation layer for Linux

#261
post #202
post #196

Earlier quoted context omitted.

Most (married) people are spending more time with their computers than their spouses. Would you marry an ugly woman? An ugly man?

Beauty is in the eye of the beholder

It certainly is! That's why I choose software that I think is beautiful.

I may think a terminal window is beautiful - if I do then I will choose a terminal.

What I won't do is purposefully use user-hostile/ugly software on principle - if there is a better choice I will choose the better choice.

Re: Darling – MacOS translation layer for Linux

#262
post #77

Earlier quoted context omitted.

I go back and forth on whether this would truly be useful. 10-15 years ago, having a fully baked, first class, slavishly source compatible implementation of GNUstep with broad adoption throughout Linux land would have likely been a game changer. But now, it seems webified apps are king. The handful of native apps that people use are already satisfactorily implementable on Linux. In fact, a great number of native apps…

I wrote a blog post once about how the web is the new presentation layer for the desktop, that this is not necessarily a bad thing, and that a desktop OS (e.g. a Linux distro) should just fully embrace it by implementing a desktop that runs 100% via web technologies. Local and remote web apps could coexist as first class citizens, etc. I basically argued that HTML+JS+CSS renderers are the new X and that HTTP(S) is th…

I got DDOSed and threatened. I got some of the most insane all-caps slobbering and frothing at the mouth feedback I have ever seen in all my years of interacting with any developer community. You'd think I went into a conservative church and gave a talk about evidence for abortion in the Bible or something.

Looking back over the decades and recalling my interaction with developers, I ask myself, when did we become an angry mob of anti-intellectual haters? Some of us are as cartoonishly awful as lords and ladies in French Revolution period dramas.

Re: Darling – MacOS translation layer for Linux

#263
post #247
post #185

Earlier quoted context omitted.

What about Ardour?

I've seen a friend use it for some basic multitrack stuff - basically recording his band live whilst practising. But, it is not a patch on something like Reaper.

You're mistaken, Ardour is comparable to ProTools, Reaper and similar DAW. It's also compatible with VST plugins, etc.

Re: Darling – MacOS translation layer for Linux

#264

Earlier quoted context omitted.

I was looking at emacs documentation the other day and thought that RMS is probably right that Linux should be called GNU/Linux. In that case, newcomers to this project might ask "What's GNU Darlin?

Gnu/Linux/Darwin == Gnarlin? Seriously though, i used to think GNU/Linux was just envy of linux' success, but Gnu basically IS OS without a kernel (Herd, where art thou?).

If you're using a distribution like Alpine Linux, which uses musl libc and busybox en lieu of much of the GNU userspace, it's not really a GNU/Linux by any definition.

Re: Darling – MacOS translation layer for Linux

#265
post #61
post #43

Earlier quoted context omitted.

SUA(SubSystem for Unix-based Applications) is litterally a BSD fork...

You mean the Unix subsystem they made just to claim POSIX compatibility, that they totally abandoned in recent Windows versions?

No, xe does not.

The subsystem that was made just to claim POSIX compatibility was the subsystem that preceded Interix. Interix was developed outwith Microsoft, and replaced the old POSIX subsystem. It was Windows NT's second POSIX subsystem, and it very much is not just a sop for the sake of checking a requirements checkbox.

It's a fairly usable POSIX environment, with a large toolset, proper terminal emulations, pseudo-terminals, interoperability with non-POSIX processes including visibility with (an enhanced) ps and the ability to send signals to Win32 processes, an actual init and inetd, and an X server.

Stephen Walli has stated that it started as a fork of 4.4BSD-Lite.

* https://news.ycombinator.com/item?id=11560510

* https://news.ycombinator.com/item?id=11416392

Re: Darling – MacOS translation layer for Linux

#266

Wouldn't be a terrible idea to do something similar for the BSDs, particularly FreeBSD. A lot of the syscalls would be passthroughs, which would make things a little easier at least.

Go and whisper in these people's ears. (-:

* http://www.nextbsd.org/

Re: Darling – MacOS translation layer for Linux

#267
post #198

Earlier quoted context omitted.

I don't understand all the downvotes for all of your comments. I have developed GUIs in Gtk, Qt, .Net, and Java+Swing, but I saw the writing on the wall and learned web dev. I really really hate writing GUIs in HTML (inferior tools, inferior performance), but that is where the wind is blowing.

There is plenty of money to be made in native GUIs, one just needs to search for the right customers. I have been developing green field native applications in the last three years. It has been a return to sanity after doing around 4 years web dev.

Any recommendations for where to look for this type of customer?

Re: Darling – MacOS translation layer for Linux

#268
post #68

Earlier quoted context omitted.

I'd be happy enough if I could run the VM.

Do you mean legally, or at all? Because if it's "at all" I believe there is a very vibrant community who have a lot of tutorials for doing that

I mean legally. And with decent performance, without overly major bugs.

Re: Darling – MacOS translation layer for Linux

#269
post #151

Earlier quoted context omitted.

OS X is UNIX 03 certified. That's a formalism. 1) That's a nearly 15-year-old standard (03 == 2003). Windows was certified to the predecessor POSIX standard. 2) While certified, it's compliance in actuality is poor. macOS's certified status says more about flaws in the certification test suite and administrative process, and the OpenGroup's need for income, than it does about macOS. The manual page for pselect, for e…

> [...] 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 calling select. It's _impossible_ to fix this race without resort to pselect, or by use of system extensions like kqueue on BSD/macOS[1] or signalfd on Linux, which can be tricky. On Solaris you just have to use pselect, or resort to the so-called "pipe trick".

So the fact that pselect is a wrapper around select admits that it's not conformant. It's basically useless; worse, it's dangerous because application code calling pselect expecting there won't be a race.

You can see the race with this code, which on 10.10.5 still fails. What should happen is that it exits immediately with OK. What actually happens on macOS is that its pselect wrapper unblocks the signal, which is immediately delivered. But by then we've already checked that interrupted was still 0. It then calls select, which will timeout because it won't be interrupted--the signal was already delivered. On every other platform implementing pselect (which all do it correctly), pselect will always return EINTR because the signal unmasking and delivery happens in the kernel _after_ entering select.

  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  
  static int interrupted;
  
  static void
  interrupt(int signo)
  {
    interrupted = signo;
  }
  
  int
  main(void)
  {
    struct timespec timeout = { 3, 0 };
    sigset_t empty, block;
    int n;
  
    sigemptyset(&empty);
    sigemptyset(&block);
  
    sigaddset(&block, SIGHUP);
    sigprocmask(SIG_BLOCK, &block, NULL);
  
    signal(SIGHUP, &interrupt);
    raise(SIGHUP);
  
    while (!interrupted) {
      /*
       * If pselect does not atomically unblock signals, pselect
       * will never be interrupted and we'll lose the signal until
       * something else wakes us up AND we remember to check even
       * though we never saw EINTR.
       */
      n = pselect(0, NULL, NULL, NULL, &timeout, &empty);
      if (n == -1 && errno != EINTR) {
        err(1, "pselect");
      } else if (n == 0) {
        errx(1, "timed out");
      }
    }
  
    if (interrupted != SIGHUP)
      errx(1, "wrong signal (got %d, expected %d)",
          interrupted, SIGHUP);
  
    puts("OK");
    
    return 0;  
  }
[1] FWIW, here's a correct implementation of pselect for macOS using kqueue. (https://github.com/wahern/cqueues/blob/snap-20160812/src/cqu...) The only caveat is that creating a kqueue descriptor might fail, and you don't normally expect pselect to fail with EMFILE or ENFILE; it might even make it non-compliant. Except for that caveat, it's a compliant implementation of pselect AFAICT.

Re: Darling – MacOS translation layer for Linux

#270
post #151

Earlier quoted context omitted.

OS X is UNIX 03 certified. That's a formalism. 1) That's a nearly 15-year-old standard (03 == 2003). Windows was certified to the predecessor POSIX standard. 2) While certified, it's compliance in actuality is poor. macOS's certified status says more about flaws in the certification test suite and administrative process, and the OpenGroup's need for income, than it does about macOS. The manual page for pselect, for e…

From PSELECT(2): STANDARDS The pselect() function conforms to IEEE Std 1003.1-2001 (``POSIX.1'').

See my reply to RJIb8RBYxzAMX9u, elsethread. It's misleading. The interface conforms, but the implementation is not compliant At least for all the version of macOS I've tested (I haven't tested 10.12, yet) the very problem pselect was created to address exists. When I said that the manual page admits it's non-compliant, I was referring to the section that said pselect was implemented as a wrapper around select; but you can't correctly implement pselect as a simple wrapper around select.

But see my link in the other reply to a correct implementation I wrote that relies on kqueue. I even submitted it to Apple years ago along with the bug report.

Post reply on HN