Forgive the naivety, but what graphical Linux apps are people trying to run that don’t have native MacOS builds? In my experience, Linux GUIs are generally written in Qt or GTK, both of which are multi-platform.
I don’t doubt that they exist, I’m just struggling to think of a popular example.
That's not the use case. The use case is running apps from a remote Linux host as a local window. A performant VNC for specific windows if you will.
For example, you could run VS Code on that machine as a window on your Mac. A more real world example is people accessing guis (e.g. matlab) on lab clusters.
The closest set up for x11 would be to use x11 forwarding with xpra.
> The closest set up for x11 would be to use x11 forwarding with xpra.
Older versions of macOS even had an X server distributed by Apple that you could install on your machine, and if memory serves right you were then easily able to forward X11 from a remote Linux host (or other operating systems running X11 applications) using ssh and have it render to your macOS desktop.
From a quick google search there is apparently still an Apple supported third-party open source project called XQuartz one can use.
https://en.wikipedia.org/wiki/XQuartz
X11 forwarding with ssh and XQuartz looks to work the same way that I remember using the Apple distributed X server in the past. Install the X server and then use the -X flag of ssh. Same way that you forward X11 between two Linux computers, or Sun workstations or whatever with an X11 desktop, over ssh.
This is Wayland. You could use xprs
wprs? Does not work for mac yet IIRC...
Or running applications within fully sandboxed VMs on the local machine, but with native-ish forwarded GUI. Great for dev.
This is Wayland. You could use xprs (or Waypipe).
Sorry, I responded to the wrong comment.
We run TurboVNC from macOS to beefy Linux servers on the daily. Just tunnel the connection over SSH. It's been solid for 5+ years.
Isn't better to run native VS Code and have remote SSH session? It very much works as if it was local (on fast low latency network). Only issue is moving files.
This is very interesting to me for two reasons:
1. I'd really like to run my development environment for things under Siri for its tiling window management but for better or worse I'm deeply embedded in the Apple ecosystem for everything else, this looks like it could be a really nice way of doing it (possibly once multi monitor support is in).
2. There are still a few applications which have supported Linux builds but no support for macOS (Iridium's Niagara Workbench application for configuration of building management systems springs to mind here). Since Apple ended support for Quartz this has been a bit of a pain to deal with.
Popular apps? Probably not many.
But in the field of integrated circuit design there’s lots of apps that are Linux-only. I’ve tried to run some of them in containers on Mac. But XQuartz is awful.
If they ever transitioned to Wayland perhaps this would let us run these apps on Mac in a nice way.
On the other hand some of them have started getting ARM builds (for running simulations on certain cloud environments) so maybe native Mac GUI builds could happen someday soon.
> But XQuartz is awful.
What issues are you seeing with it? I use it pretty heavily and have no complaints…
- [deleted]
What about this plus XWayland? Would that do it?
Apart from just running Linux apps, you can use this to run graphical applications remotely on a Linux server, like X11 forwarding.
I thought Wayland was different from X11, and didn't allow this. But I'm far from an expert on this topic so I'd like to learn more.
Wayland natively isn’t built for forwarding the way X11 is. Waypipe fixes this, providing an X11 protocol equivalent for Wayland. This project is a waypipe client for macOS.
https://github.com/neonkore/waypipe proxies Wayland over a network. It’s straightforward enough in theory: Wayland core is just a communications protocol plus shared memory; so you just need to forward the messages, and detect and send changes in the shared memory. Not the cheapest thing, but perfectly tractable. Of course, there are also more difficult extensions, like GPU integration, but that sort of thing was a problem for X as well.
This is how modern x11 worked too since nobody uses software rendering with x primitives anyway.
here is Wayland vs X11 visualised.. it might help - https://vectree.io/c/compositing-window-management-architect...
- [deleted]
According to that page Wayland's architecture is simpler than X11.
If you put everything into a monolith, it looks simpler than if you have components that have to speak protocols to each other.
Rio and its predecesor in Unix v8/v10 did it better than X. In some cases we got the worst:
- POSIX bloat vs Plan9's simple C and even simpler API
- ioctl's vs everything it's a file
- Complex socket spawning vs open() and dial() under Plan9/Go
- ALSA vs tuned up OSSv4, or plaing audio/mixerfs under 9front
- find -which syntax is huge- vs walk -f (or -d for dirs) | grep
- RDP/VNC/SSH/NFS/SMB vs just rcpu+auth (9p) and run rio(4) and for files... 9fs which does a simple bind()
- Symlinks and hard links vs bind and namespaces.
- GDB and SSH vs importing a remote /proc in a rio window and remote-debugging your damn remote machine as if it were your own. How cool is that? Ditto with devices. Import sound cards, network cards with the whole IP stack. NAT you say? No more.
- FFSv2 (hello OpenBSD) vs current GeFS under 9front which is like a miracle over what OBSD it's trying, the bad ZFS license or BTRFS not being ready on GNU yet. Probably the Hurd people will port GeFS to Hurd/Mach first, before BTRFS gets even ready...
- Dynamic vs static linking. 9front, a suite of multiarch compilers. Set $objtype, compile, link, deploy a standalone binary. Ready, as if it were a Go binary under Unix, but without glibc oddities. ARM binaries from 386? Done. You need a crazy long i686-gnu-foo-bar and the rest of crazyness? Not anymore. These come in src form, compile and install them, no internet required. Literal two damn commands to do so, from any to any arch.
- SH/KSH/Bash. Complexity ridden shells. Here's rc. No aliases there, just functions. No complex escaping, just () for strings, ^ to concat, ' ' for quoting. Problem solved. Even the conditonal words' syntax it's like throwing down all the complexity giving you a weirdly simple shell.
- PCRE and ex commands under vi/nvi/vim (bloat) vs Sam and structural regexes. Sam it's like a graphical vi, period, there's nothing alien of it. Imagine a modeless vi with a small frame to input commands with an easier syntax:
These can be chained with ease.x/lookup/c/replace
I want to use KDE Plasma instead of Mac OS ugly (in my opinion) interface
This is possibly the first time in human history this opinion has been stated.
I've been using Linux on the desktop for decades at this point. KDE Plasma is my current favorite and I've been using it for a few years now. It has everything you'd want in a desktop (maybe a bit more), looks great, and is very fast even on modest hardware.
My current job has me using MacOS on an M3 Pro Macbook and I find it barely tolerable compared to KDE. Usually when I want to do something new or change some configuration, either there is no way to do it, or it's hidden behind some key combination that I never would have guessed. I would describe the overall feel of MacOS as "syrupy." When using the mouse or typing, there is almost always some kind of barely-perceptible latency. Nothing is ever crisp and instant. (This isn't specific to this machine, it feels the same way on every Mac I've borrowed.) It's sort of like someone decided that the only way to make it smooth was to also make it slow.
It really isn’t. There are a great many people who use macs for work but who do not like Apples design choices. And that number has skyrocketed even further since Liquid Glass was pushed onto people.
In fact one of the front page articles today is literally calling macOS “ugly” in the title.
I don't want KDE but I would much prefer gnome to macos desktop, I think it's both prettier and more functional, and that's not a tahoe thing. I hate finder too, and don't see any way to properly use an alternative.
not sure about the looks but I also find KDE much better in usability
Similar opinions are voiced in about every recent macOS UI thread, and even occasionally in Windows threads.
I mean Apple hasn't done itself any favours with Macos Tahoe.
“Liquid Ass” as some people say.
To be honest, I agree a little bit because I remember from my time at customizing KDE that everyone wanted it to make it look like Mac OS
but it feels a bit of peer-pressure/cool-factor, people used to like how Mac OS look but after Tahoe, I feel like most people don't.
To be honest, I am on mac right now but I really like Niri/Hyprland and to a degree KDE as well. I definitely feel like those were immensely more customizable and I miss that customizability, even if some people might use that customizability to make it look like MacOS default.
Then you want to run KDE on Linux. This is not going to replace your native mac desktop environment.
Honest question: why use MacOS at all then? If you prefer KDE, why not run a system that KDE natively supports? Is it a particular MacOS application? Or is it that Linux support on Mac hardware is not good enough?
Linux has good support for m1 and m2, so for newer devices running a custom desktop would be neat.
I think there are many use cases for this software.
For example, you may not want to run some graphical applications directly on your Mac for security, isolation or testing purposes.
If this software turns out to be lower latency than RDP and CRD, I could also see it being very useful for accessing a remote graphical workstation (e.g.: running heavy software on an beefy machine in a data center instead of taking up resources on my skinny laptop).
The first thing I wondered about was running GUI apps in a Linux container.
There’s a bunch of old Fortran stuff I use regularly (AVL, XFoil), but that’s all X, not Wayland, and XQuartz has worked great for decades.
It's not necessarily something only available for Linux, but something that you want to containerise. (And then it's inherently running on Linux.)
Emacs runs much faster and better on Linux VMs. And I have a VM for each client I work with.
Try building Inkscape or GIMP from source on macOS and see how "multi-platform" those GTK apps feel in practice. Even when a Mac build exists, it is often skinned oddly or lags because somebody has to carry Mac patches against an old fork.
This is for the long tail. The compositor path dodges a pile of volunteer-port churn and runs the Linux build directly, which is a lot more appealing for niche GUI tools and dev apps that barely get maintained on Linux, never mind macOS.
Native GTK apps on macOS are often more broken than running it in a VM or Parallels, in my experience. I used to use Gitg on macOS and it was a terrible experience all around.
PuTTY
That's a Windows app.
PuTTY is absolutely available for Linux. On Debian-based distros it’s just a `sudo apt install putty` away. But why?
One possibility is to run its terminal emulation somewhere else. But of course terminal emulators are a dime a dozen on Linux.