121–130 of 138 posts
Nice. Off topic, but does anyone know of any good IINA alternatives for Linux? I have not found anything that beats it in terms of polish. VLC is nice, but IINA does one thing really well, and is based on MPV, with all of its powerful configuration options and nice keybinds.
I've had good experiences using gnome-mpv, (now called Celluloid) it's minimalistic, but I really like it. https://celluloid-player.github.io/
Earlier quoted context omitted.
Not sure it's the underlying reason, but for a long while Go would use raw syscalls on Darwin, which is something that Windows has explicitly sabotaged for ages. It's a lot easier to trap a library call from userspace than a syscall.
If this documentation is accurate, Darling doesn't support raw syscalls either: https://wiki.darlinghq.org/documentation:system_call_emulati... Their Linux kernel module does seem to be XNU based, but it feels like poor design / a rushed job to run it as a Linux kernel module instead of isolating it in userspace.
You see, people think XNU is just another kernel, but it's very different from Linux or the Windows kernel. The only reason why we need a kernel module is Mach IPC. But this IPC is so critical and omni-present that a user-space process cannot even do a sleep() without using it. Even event loops in every GUI application use Mach IPC on the lowest level.
There is no way of implementing the full semantics of this IPC mechanism without a help from the kernel. For example, Mach IPC involves making direct memory copies between processes.
So even if we decided to take the "wineserver" approach, which would set us back by several years, the result would be super slow and not very compatible.
Also the userspace on macOS is quite different from other operating systems, which is why it's all taking us so long. MacOS is a bloated system with a huge number of layers sitting between the UI toolkit and the windowing server.
Imagine creating Wine from scratch. How much functionality would you need to implement to provide the correct behavior for a super-simple native GUI application? Probably just USER32, GDI32 and KERNEL32 would do. On MacOS, this is AppKit, QuartzCore, Foundation, CoreFoundation, libobjc and libSystem (which includes huge components such as libdispatch and emulating complex APIs such as kqueue).
FYI: The reason why we don't emulate raw syscalls is because this is not possible from kernel modules, unless you resort to techniques that could easily destabilize the whole system.
Earlier quoted context omitted.
As far as raster graphics, Krita, GIMP, and Darktable can get you professional results without needing to resort to closed-source software.
I use DT almost exclusively for my photo editing since over a decade. While it is absolutely true that you can do professional work with this you have a very steep learning curve, bad UX and feature overload. The latter is really a core reason for the bad UX: developers love to add features. Every feature you add becomes another module or another slider. Every slider or widget you add creates an extra dimension for t…
Earlier quoted context omitted.
As far as raster graphics, Krita, GIMP, and Darktable can get you professional results without needing to resort to closed-source software.
My impression is that Krita is for digital painting and not for photo editing, is that not the case?
Earlier quoted context omitted.
No GUI apps (well, kinda). But you can run WebKit on Linux already, if that helps.
Could you elaborate on running WebKit on Linux? Is it the same engine that latest Safari release is using?
Earlier quoted context omitted.
The —help is not particularly useful when you have proper man pages.
It is often less verbose than a man page so can be seen entirely without a pager, which is often all you need when you are looking for a reminder of that periodically used option. Certainly having both options (man page and inline help) is better than having only one option.
Unrelated comment, but am i the only one who gets annoyed by the "does it runs safari?" or "does it runs adobe?" questions? It seems a significant portion of "readers" can't or won't actually read, which is pretty ironic on a news site. I hate this.
Earlier quoted context omitted.
Wow is that true? A lot of people could save a shit ton of money for that CI and automatic tooling for macOS, iOS and so on
I'm discovering this too, and quite eager to try, being able to build iOS apps on Linux would be a big step forward for CI/CD. I just found this documentation from Godot: https://docs.godotengine.org/en/stable/development/compiling... Actually, there's an xcode example in the doc as well: https://wiki.darlinghq.org/what_to_try
Earlier quoted context omitted.
If this documentation is accurate, Darling doesn't support raw syscalls either: https://wiki.darlinghq.org/documentation:system_call_emulati... Their Linux kernel module does seem to be XNU based, but it feels like poor design / a rushed job to run it as a Linux kernel module instead of isolating it in userspace.
Rushed job? We've been at this for almost 8 years. We tried doing this without a kernel module for several years, but it just wasn't feasible. You see, people think XNU is just another kernel, but it's very different from Linux or the Windows kernel. The only reason why we need a kernel module is Mach IPC. But this IPC is so critical and omni-present that a user-space process cannot even do a sleep() without using it…
> How much functionality would you need to implement to provide the correct behavior for a super-simple native GUI application? Probably just USER32, GDI32 and KERNEL32 would do. On MacOS, this is AppKit, QuartzCore, Foundation, CoreFoundation, libobjc and libSystem (which includes huge components such as libdispatch and emulating complex APIs such as kqueue).
I don't think "number of APIs" is the reasonable benchmark for how difficult it might be to get a GUI application up and running. It's totally possible that macOS might more eagerly split out functionality into different systems while Windows combines that same functionality into relatively few. I don't know how true that is, but it'd be interesting to compare based on the depth of those libraries rather than just the quantity.
And from what I understand about Wine, all three of those Windows libraries are incredibly complex and convoluted, and even to this day have gaps in their Wine equivalents. Assuming macOS' greater quantity of necessary libraries add up to the same degree of API surface to be reimplemented, what y'all are doing is impressive, to say the least (and sure, Wine's more usable right now, but Wine also had a decade or two of a head start).
Earlier quoted context omitted.
It is often less verbose than a man page so can be seen entirely without a pager, which is often all you need when you are looking for a reminder of that periodically used option. Certainly having both options (man page and inline help) is better than having only one option.
If you can’t find what you need in the man page, because of the bloat, well, it’s the bloat that’s the problem, not the lack of —help.