People have been trying to make Unix-y desktop environments look like Mac OS for just about forever – I recall some truly hideous ones in the 2000s – but I’ve never seen one get close enough to even achieve an uncanny-valley effect. Looking at the screenshots, this is yet another one that’s not even close.
And in general the idea of “finesse of macOS” on a *nix desktop environment is contradictory. You can’t have both the “freedom of (insert your favorite OS here)” and the level of enforced conformity of interface design and other niceties that makes macOS actually nice to use. There simply are too many developers out there building too many applications which will refuse to adopt the necessary conventions, and the project almost certainly doesn’t have the resources to fork and maintain all of them.
The trouble is that people focus on trivial cosmetics rather than structure & function. Themes, for example: those are just not important.
Ubuntu’s Unity desktop got a lot of the OS X user-level functionality. A dock/launcher that combined open windows with app launchers, which had indicators to show not only that a window was open (Mac OS X style) but how many windows were open (a gain over OS X), and had a standardised mechanism for opening additional empty windows (another gain over OS X).
But people didn’t register that, because it was on the left. Apple’s is at the bottom by default (although you can move it, but many people seem not to know that.) NeXT’s was at the right, but that’s partly because NeXT’s scrollbars were on the left.
Cosmetics obscured the functional similarity.
Unity showed that a global menu bar on Linux was doable, and somehow, I don’t know how, Unity did it for Gtk apps and for Qt apps and for apps using other frameworks or toolkits. Install new software from other desktops and it acquired a global menu bar. Still works for Google Chrome today. Works for the Waterfox browser today, but not for Firefox.
On top of that, Unity allowed you to use that menu with Windows shortcut keystrokes, and Unity’s dock accepted Windows’ Quick Launch bar keystrokes. But that went largely unnoticed too, because all the point-and-drool merchants don’t know that there are standard Windows keystrokes or how to use them.
Other aspects can be done as well: e.g. Mac OS X’s .app bundles are implemented in GNUstep, with the same filenames, the same structure, the same config files, everything. And simpler than that, AppImages provide much the same functionality. So does GoboLinux.
This stuff can be implemented on FOSS xNix: the proof is that it’s already been done.
But nobody’s brought the pieces together in one place.
Making the same keyboard shortcuts work everywhere. Even little things like the navigation within a text field can behave differently between toolkits, though the big distros have configured at least GTK and Qt to behave the same way. Beyond that, on macOS, command-, will open preferences in any application that has preferences. Command-shift-v pastes and matches style in every application that has rich text. There are a load of shortcuts that are the same everywhere. Apple achieved this by having XCode (and, before that, Interface Builder) populate the default menu bar with all of these shortcuts preconfigured. This is much harder to do with a diverse tooling ecosystem.
Drag and drop works everywhere. It’s somewhat embarrassing that drag-and-drop works better between MS Office apps on macOS than Windows. There are a couple of things that make this work well on macOS:
The drag-and-drop protocol has a good content-negotiation model. The drag source provides a list of types that it can provide. The drop target picks one. The drag source then provides the data. This means that there’s no delay on drag start (you just need to provide a list of types, which is trivial, the Windows and Wayland models both encourage you to provide the drag data up front). It also means that you can do complex transcoding things on drop, where users are more tolerant of delay.
There’s a built-in type for providing a file promise, where I can offer a file but not actually need to write it to the filesystem until the drop operation completes. This means, for example, I can drag a file from a Mail.app attachment and it doesn’t need to do the base64 decode and write the file until the drop happens.
There are some things that could be improved, but this model has worked pretty well since 1988. It’s significantly augmented by the fact that there’s a file icon in the title bar (newer macOS has hidden this a bit) that means that any document window has a drag source for the file. I can, for example, open a PDF in Preview and then drag from the title bar onto Mail.app’s icon to create a new file with that PDF file as an attachment.
The global menu bar mostly works with Qt and GTK applications but it requires applications to have separate app and document abstractions, which a lot of things that aim for a Windows-like model lack. Closing the last window in a macOS app doesn’t quit the app, it leaves the menu bar visible and so you can close one document and then create a new one without the app quitting out from under you. The Windows-equivalent flow requires you to create the new doc and then close the old one, which I find jarring.
The macOS model works particularly well on XNU because of the sudden termination mechanism that originated on iOS. Processes can explicitly park themselves in a state where they’re able to be killed (with the equivalent of kill -9) at any point. They are moved out of this state when input is available on a file descriptor that they’re sleeping on. This means that apps can sit in the background with no windows open and be killed if there’s memory pressure.
Sudden termination requires a bunch of cooperation between different bits of the stack. For example, the display server needs to own the buffers containing the current window contents so that you can kill an app without the user seeing the windows go away. When the user selects the window, then you need the window server to be able to relaunch the app and give it a mechanism to reattach to the windows. It also needs the window server to buffer input for things that were killed and provide it on relaunch. It also needs the frameworks to support saving state outside of the process.
Apple has done a lot of work to make sure that everything properly supports this kind of state preservation across app restarts. My favourite example is the terminal, which will restore all windows in the same positions and a UUID in an environment variable. When my Mac reboots, all of my remote SSH sessions are automatically restored by a quick check in my .profile to see if I have a file corresponding to the session UUID and, if so, reading it and reestablishing the remote SSH session.
I prefer not to engage with comments that resort to phrases like “point-and-drool”.
But I’ll point out that you’re not really contradicting here – Unity was a significant amount of work that basically required an entity with the funding level of Ubuntu to pull off even briefly, and in general Ubuntu’s efforts to make the desktop experience more “polished” and easier have been met with outright hostility. Heck, even just GNOME tends to get a lot of hate for this: when they try to unify, simplify, and establish clear conventions, people attack them for “dumbing down”, for being “control freaks”, for their “my way or the highway” approach, for taking away freedom from developers/users/etc., and that ought to be the clearest possible evidence for my claim about the general contradiction between wanting the “finesse” of macOS with the “freedom” of a Free/open-source stack.
I prefer not to engage with comments that resort to phrases like “point-and-drool”.
[Surprised] What’s wrong with it? It is fairly mildly condemnatory, IMHO. FWIW, I am not an American and I do not generally aim to conform to American cultural norms. If this is particularly offensive, it’s news to me.
I completely agree that Unity was a big project and a lot of work, which was under-appreciated.
But for me, a big difference is that Unity attempted to keep as many UI conventions as it could, to accommodate multiple UI method: mainly keyboard-driven and mainly pointing-device driven; Windows-like conventions (.e.g window and menu manipulation with the standard Windows keystrokes) and Mac-like conventions (e.g. a global menu bar, a dock, etc.)
GNOME, to me, says: “No, we’re not doing that. We don’t care if you like it. We don’t care if you use it. We don’t, and therefore, it’s not needed. You don’t need menu bars, or title bars, or desktop icons, or a choice of sidebar in your filer, or any use for that big panel across the top of the screen. All that stuff is legacy junk. Your phone doesn’t have it, and you use that, therefore, it’s baggage, and we are taking all that away, so get used to it, move on, and stop complaining.”
People have been trying to make Unix-y desktop environments look like Mac OS
Starting with Apple. :-). macOS is Unix.
And in general the idea of “finesse of macOS” on a *nix desktop environment is contradictory.
Considering the above, that seems … unlikely. Or maybe macOS is a contradiction onto itself?
NeXTstep arguably had even higher standards.
It’s funny, because I use the old “stable but ugly server os vs. pretty+easy-to-use but crashy client OS”-dichotomy as an example of things we used to believe were iron laws of nature, but that turned out to be completely accidental distinctions that were swept away by progress.
My phone is running Unix, and so is just about everybody’s. I think my watch is running Unix as well.
and the level of enforced conformity of interface design
Considering how crappy the built in apps are these days compared to 3rd party apps, and how little they conform to any rules or guidelines, I think that’s at best a highly debatable claim.
A lot of the “finesse” of macOS actually isn’t in superficial appearance, though, it’s in systemwide conventions that are essentially impossible to enforce in a useful way without also bringing in the level of platform control that’s alleged to be evil when Apple does it.
Right, there’s a lot of subtle things you’d have to enforce within the ecosystem to make it work even close - just the notion of NSApplication and friends is alien to a world where it’s assumed a process has to have a window to exist in the GUI.
People have been trying to make Unix-y desktop environments look like Mac OS
Starting with Apple. :-). macOS is Unix.
I think if you read “unix-y desktop environments” where “unix-y” modifies “desktop environment” as opposed to as “unixes that have a desktop environment” (eg as “X11 DEs/WMs such as GNOME/KDE/Englightenment”) I think this observation is more compelling. A common theme of most phones, most (all?) watches, NextStep and Mac OS is that they are very much not running “a unix-y desktop environment.”
If I want a Mac, I’ll buy a Mac. What’d be more interesting is trying to build something better. Despite Gnome 3’s flaws, I do appreciate it at least tried to present a desktop model other than “Mac OS” or “Windows 98”.
I personally hate the model it proposes, but you make a good point: at least it’s not the same old same old.
Oddly, Pop OS pleases me more, because it goes further. Pop OS, to me, says:
“OK, so, GNOME took away your ability to manage windows on the desktop and it expects you to just use one virtual desktop per app. Window management is for simps; use it like a phone, all apps full screen all the time. We don’t think that’s enough, so, we’re going to keep GNOME but slap a tiling window manager on top, because we respect that you might not have a vast desktop or want one app per screen, so let us help you by automating that stuff… without sacrificing a desktop environment and switching to some kind of alien keyboard-driving tiling window-manager thing that takes away everything you know.”
Isn’t SerenityOS an example of finesse of macos with some level of open source freedom?
It depends how you define freedom, but they seem to have a lot of different people working on different things entirely that are still built on a shared vision seemingly quite well, it is still early but i wouldnt give up on the idea all together.
I understand what you are saying, but I think its an interesting compromise thats surprisingly effective (from the outside perspective)
As someone with a pretty long history of using Linux on the desktop (and even FreeBSD for a while) I guess some of us are at certain points in time fed up with the complete fragmentation of stuff and are thus either converging or hoping for that one magical desktop interface/DE/window manager that gets enough traction for it to be really good without having to fiddle around.
I know tons of Mac users who are not 100% happy with OSX, but they’re still a lot happier than with any flavor of desktop environment on Linux, so OSX doesn’t seem to be too bad of a benchmark.
I wonder what this could look like on top of the DragonflyBSD kernel - IIRC, it has some interesting IPC mechanisms that I bet could be bent into Apple-like shapes.
Perhaps it could, but I don’t think anything kernel-level is relevant yet.
Even if Dragonfly’s kernel had some clever stuff, it wouldn’t matter: Linux apps won’t use it, and the 0.1% of the FOSS world writing xBSD-specific apps won’t use it, because (extremely approximate finger-in-the-air guesstimate) the usage is something like…
DragonflyBSD users are 1% of NetBSD users, which are 1% of OpenBSD users, which are 1% of FreeBSD users.
FreeBSD is actually out there in real numbers. Maybe in the millions. OpenBSD’s own estimates are, I think I’ve read, in the tens of thousands? NetBSD aren’t talking to me (literally; I’ve asked – I reviewed it a couple of weeks ago) but I suspect in the thousands if that, and many on obsolete kit that can’t run modern apps because it has RAM in the tens of megabytes range.
DragonFly… we could be talking user numbers of hundreds. Maybe even less.
For clarity: I’d love to be wrong about this. Anyone: please please please falsify and refute this if you can.
Perhaps it could, but I don’t think anything kernel-level is relevant yet.
I think you’re wrong about this; if you check their release notes you’ll see that they’re working on a Mach subsystem and an implementation of XPC, which is what made me wonder if building on Dragonfly’s IPC mechanisms might be a boon.
Even if Dragonfly’s kernel had some clever stuff, it wouldn’t matter: Linux apps won’t use it, and the 0.1% of the FOSS world writing xBSD-specific apps won’t use it, because (extremely approximate finger-in-the-air guesstimate) the usage is something like…
I don’t know much about the popularity of the various BSDs relative to each other, but I’m not sure that it matters here. Compatibility with Linux or any of the other BSDs seems largely irrelevant to the goals of this project.
The main IPC mechanism that XNU provides and FreeBSD doesn’t is Mach ports. macOS uses these mostly for the explicit trailer information that the kernel can add (which is also the reason that they were so slow and why Mach gave microkernels a terrible name). These let you add a bunch of security metadata into messages. For example, when you send a Mach message to the keychain service, the recipient knows your UID, who signed your binary, the program name, and a few other useful things. This lets it implement access control policies like ‘this key may be released only to version X of FooCorp’s BarApp or newer’.
The other nice thing on macOS is the notify APIs. These basically provide a 1-bit communication channel per number and let you have a small number of them in a shared page for polling and a larger number that you can use with kqueue. These are used for kernel to userspace communication in a number of places.
I don’t think that Dragonfly’s message-passing mechanism would help with either of these but I could be wrong.
One thing I really want on my Linux since Unity is a searchable global menubar.
If they can get it to work in a gtk4 wayland world, I’d be extatic. Unfortunately gtk4 doesn’t seem to have a concept of a manu bar and gtk3 doesn’t expose it to dbus when running under wayland.
It’s also a shame how many GUI toolkits still haven’t figure out how to expose a buffer to Wayland and still rely on XWayland to this day (Looking at you JavaFX and Chromium/Electron)
Searchable? You want a search box for the text in the UI?
Yes, that was a thing Unity did: Ubuntu called it the HUD. I hated it myself and wanted a way to turn it off. I don’t know any other desktop that ever did that.
I’m intrigued to find another of the very few people who I ever saw say that they liked it.
Not sure how far along the UI side of things is, but if the project manages to build a UI framework that’s properly integrated with the rest of the OS and marginally nicer than Qt/GTK, I’d be very interested in seeing where it goes. I’m not a big fan of Obj-C or Cocoa, but at this point I just want some viable alternatives to Qt and GTK :\
My benchmark for if an OS is usable is if it can run a modern, hardware-accelerated browser. If the screenshots are up-to-date and they really have Firefox running on the new framework, that’s already a huge win. I definitely would be happy to pay for an open source nix-like OS that has a better lightweight desktop/laptop experience than what Linux currently offers. XFCE is fine, but certainly has some rough edges.
People have been trying to make Unix-y desktop environments look like Mac OS for just about forever – I recall some truly hideous ones in the 2000s – but I’ve never seen one get close enough to even achieve an uncanny-valley effect. Looking at the screenshots, this is yet another one that’s not even close.
And in general the idea of “finesse of macOS” on a *nix desktop environment is contradictory. You can’t have both the “freedom of (insert your favorite OS here)” and the level of enforced conformity of interface design and other niceties that makes macOS actually nice to use. There simply are too many developers out there building too many applications which will refuse to adopt the necessary conventions, and the project almost certainly doesn’t have the resources to fork and maintain all of them.
I am not so sure.
The trouble is that people focus on trivial cosmetics rather than structure & function. Themes, for example: those are just not important.
Ubuntu’s Unity desktop got a lot of the OS X user-level functionality. A dock/launcher that combined open windows with app launchers, which had indicators to show not only that a window was open (Mac OS X style) but how many windows were open (a gain over OS X), and had a standardised mechanism for opening additional empty windows (another gain over OS X).
But people didn’t register that, because it was on the left. Apple’s is at the bottom by default (although you can move it, but many people seem not to know that.) NeXT’s was at the right, but that’s partly because NeXT’s scrollbars were on the left.
Cosmetics obscured the functional similarity.
Unity showed that a global menu bar on Linux was doable, and somehow, I don’t know how, Unity did it for Gtk apps and for Qt apps and for apps using other frameworks or toolkits. Install new software from other desktops and it acquired a global menu bar. Still works for Google Chrome today. Works for the Waterfox browser today, but not for Firefox.
On top of that, Unity allowed you to use that menu with Windows shortcut keystrokes, and Unity’s dock accepted Windows’ Quick Launch bar keystrokes. But that went largely unnoticed too, because all the point-and-drool merchants don’t know that there are standard Windows keystrokes or how to use them.
Other aspects can be done as well: e.g. Mac OS X’s
.appbundles are implemented in GNUstep, with the same filenames, the same structure, the same config files, everything. And simpler than that, AppImages provide much the same functionality. So does GoboLinux.This stuff can be implemented on FOSS xNix: the proof is that it’s already been done.
But nobody’s brought the pieces together in one place.
There are a few things that are harder:
Making the same keyboard shortcuts work everywhere. Even little things like the navigation within a text field can behave differently between toolkits, though the big distros have configured at least GTK and Qt to behave the same way. Beyond that, on macOS, command-, will open preferences in any application that has preferences. Command-shift-v pastes and matches style in every application that has rich text. There are a load of shortcuts that are the same everywhere. Apple achieved this by having XCode (and, before that, Interface Builder) populate the default menu bar with all of these shortcuts preconfigured. This is much harder to do with a diverse tooling ecosystem.
Drag and drop works everywhere. It’s somewhat embarrassing that drag-and-drop works better between MS Office apps on macOS than Windows. There are a couple of things that make this work well on macOS:
There are some things that could be improved, but this model has worked pretty well since 1988. It’s significantly augmented by the fact that there’s a file icon in the title bar (newer macOS has hidden this a bit) that means that any document window has a drag source for the file. I can, for example, open a PDF in Preview and then drag from the title bar onto Mail.app’s icon to create a new file with that PDF file as an attachment.
The global menu bar mostly works with Qt and GTK applications but it requires applications to have separate app and document abstractions, which a lot of things that aim for a Windows-like model lack. Closing the last window in a macOS app doesn’t quit the app, it leaves the menu bar visible and so you can close one document and then create a new one without the app quitting out from under you. The Windows-equivalent flow requires you to create the new doc and then close the old one, which I find jarring.
The macOS model works particularly well on XNU because of the sudden termination mechanism that originated on iOS. Processes can explicitly park themselves in a state where they’re able to be killed (with the equivalent of
kill -9) at any point. They are moved out of this state when input is available on a file descriptor that they’re sleeping on. This means that apps can sit in the background with no windows open and be killed if there’s memory pressure.Sudden termination requires a bunch of cooperation between different bits of the stack. For example, the display server needs to own the buffers containing the current window contents so that you can kill an app without the user seeing the windows go away. When the user selects the window, then you need the window server to be able to relaunch the app and give it a mechanism to reattach to the windows. It also needs the window server to buffer input for things that were killed and provide it on relaunch. It also needs the frameworks to support saving state outside of the process.
Apple has done a lot of work to make sure that everything properly supports this kind of state preservation across app restarts. My favourite example is the terminal, which will restore all windows in the same positions and a UUID in an environment variable. When my Mac reboots, all of my remote SSH sessions are automatically restored by a quick check in my
.profileto see if I have a file corresponding to the session UUID and, if so, reading it and reestablishing the remote SSH session.I prefer not to engage with comments that resort to phrases like “point-and-drool”.
But I’ll point out that you’re not really contradicting here – Unity was a significant amount of work that basically required an entity with the funding level of Ubuntu to pull off even briefly, and in general Ubuntu’s efforts to make the desktop experience more “polished” and easier have been met with outright hostility. Heck, even just GNOME tends to get a lot of hate for this: when they try to unify, simplify, and establish clear conventions, people attack them for “dumbing down”, for being “control freaks”, for their “my way or the highway” approach, for taking away freedom from developers/users/etc., and that ought to be the clearest possible evidence for my claim about the general contradiction between wanting the “finesse” of macOS with the “freedom” of a Free/open-source stack.
[Surprised] What’s wrong with it? It is fairly mildly condemnatory, IMHO. FWIW, I am not an American and I do not generally aim to conform to American cultural norms. If this is particularly offensive, it’s news to me.
I completely agree that Unity was a big project and a lot of work, which was under-appreciated.
But for me, a big difference is that Unity attempted to keep as many UI conventions as it could, to accommodate multiple UI method: mainly keyboard-driven and mainly pointing-device driven; Windows-like conventions (.e.g window and menu manipulation with the standard Windows keystrokes) and Mac-like conventions (e.g. a global menu bar, a dock, etc.)
GNOME, to me, says: “No, we’re not doing that. We don’t care if you like it. We don’t care if you use it. We don’t, and therefore, it’s not needed. You don’t need menu bars, or title bars, or desktop icons, or a choice of sidebar in your filer, or any use for that big panel across the top of the screen. All that stuff is legacy junk. Your phone doesn’t have it, and you use that, therefore, it’s baggage, and we are taking all that away, so get used to it, move on, and stop complaining.”
Starting with Apple. :-). macOS is Unix.
Considering the above, that seems … unlikely. Or maybe macOS is a contradiction onto itself?
NeXTstep arguably had even higher standards.
It’s funny, because I use the old “stable but ugly server os vs. pretty+easy-to-use but crashy client OS”-dichotomy as an example of things we used to believe were iron laws of nature, but that turned out to be completely accidental distinctions that were swept away by progress.
My phone is running Unix, and so is just about everybody’s. I think my watch is running Unix as well.
Considering how crappy the built in apps are these days compared to 3rd party apps, and how little they conform to any rules or guidelines, I think that’s at best a highly debatable claim.
A lot of the “finesse” of macOS actually isn’t in superficial appearance, though, it’s in systemwide conventions that are essentially impossible to enforce in a useful way without also bringing in the level of platform control that’s alleged to be evil when Apple does it.
Right, there’s a lot of subtle things you’d have to enforce within the ecosystem to make it work even close - just the notion of NSApplication and friends is alien to a world where it’s assumed a process has to have a window to exist in the GUI.
I think if you read “unix-y desktop environments” where “unix-y” modifies “desktop environment” as opposed to as “unixes that have a desktop environment” (eg as “X11 DEs/WMs such as GNOME/KDE/Englightenment”) I think this observation is more compelling. A common theme of most phones, most (all?) watches, NextStep and Mac OS is that they are very much not running “a unix-y desktop environment.”
If I want a Mac, I’ll buy a Mac. What’d be more interesting is trying to build something better. Despite Gnome 3’s flaws, I do appreciate it at least tried to present a desktop model other than “Mac OS” or “Windows 98”.
Yes, I have to give you that.
I personally hate the model it proposes, but you make a good point: at least it’s not the same old same old.
Oddly, Pop OS pleases me more, because it goes further. Pop OS, to me, says:
“OK, so, GNOME took away your ability to manage windows on the desktop and it expects you to just use one virtual desktop per app. Window management is for simps; use it like a phone, all apps full screen all the time. We don’t think that’s enough, so, we’re going to keep GNOME but slap a tiling window manager on top, because we respect that you might not have a vast desktop or want one app per screen, so let us help you by automating that stuff… without sacrificing a desktop environment and switching to some kind of alien keyboard-driving tiling window-manager thing that takes away everything you know.”
Isn’t SerenityOS an example of finesse of macos with some level of open source freedom?
It depends how you define freedom, but they seem to have a lot of different people working on different things entirely that are still built on a shared vision seemingly quite well, it is still early but i wouldnt give up on the idea all together.
I understand what you are saying, but I think its an interesting compromise thats surprisingly effective (from the outside perspective)
How many macOS-likes based on FreeBSD does this make now? Airyx? Hello?
It’d be nice if someone had a table comparing them in terms of their design goals, and how far long they are.
this is a rebranding of airyx due to some sort of name clash
This is Airyx, and Airyx is a fork of Hello.
So, so far, using your metric: 1.
As someone with a pretty long history of using Linux on the desktop (and even FreeBSD for a while) I guess some of us are at certain points in time fed up with the complete fragmentation of stuff and are thus either converging or hoping for that one magical desktop interface/DE/window manager that gets enough traction for it to be really good without having to fiddle around.
I know tons of Mac users who are not 100% happy with OSX, but they’re still a lot happier than with any flavor of desktop environment on Linux, so OSX doesn’t seem to be too bad of a benchmark.
It would be a god-send if the GNOME and KDE people merged into one super team. It could very well change the world.
What would be the result of trying to satisfy both GNOME and KDE users, aside from a monstrous DE and two forks?
It’s the users you want to merge, not the devs. And that is not really possible :)
I dont want to merge the projects, just the people! A new project would be formed :)
I wonder what this could look like on top of the DragonflyBSD kernel - IIRC, it has some interesting IPC mechanisms that I bet could be bent into Apple-like shapes.
Perhaps it could, but I don’t think anything kernel-level is relevant yet.
Even if Dragonfly’s kernel had some clever stuff, it wouldn’t matter: Linux apps won’t use it, and the 0.1% of the FOSS world writing xBSD-specific apps won’t use it, because (extremely approximate finger-in-the-air guesstimate) the usage is something like…
DragonflyBSD users are 1% of NetBSD users, which are 1% of OpenBSD users, which are 1% of FreeBSD users.
FreeBSD is actually out there in real numbers. Maybe in the millions. OpenBSD’s own estimates are, I think I’ve read, in the tens of thousands? NetBSD aren’t talking to me (literally; I’ve asked – I reviewed it a couple of weeks ago) but I suspect in the thousands if that, and many on obsolete kit that can’t run modern apps because it has RAM in the tens of megabytes range.
DragonFly… we could be talking user numbers of hundreds. Maybe even less.
For clarity: I’d love to be wrong about this. Anyone: please please please falsify and refute this if you can.
I think you’re wrong about this; if you check their release notes you’ll see that they’re working on a Mach subsystem and an implementation of XPC, which is what made me wonder if building on Dragonfly’s IPC mechanisms might be a boon.
I don’t know much about the popularity of the various BSDs relative to each other, but I’m not sure that it matters here. Compatibility with Linux or any of the other BSDs seems largely irrelevant to the goals of this project.
OK, fair enough. You make valid points.
The main IPC mechanism that XNU provides and FreeBSD doesn’t is Mach ports. macOS uses these mostly for the explicit trailer information that the kernel can add (which is also the reason that they were so slow and why Mach gave microkernels a terrible name). These let you add a bunch of security metadata into messages. For example, when you send a Mach message to the keychain service, the recipient knows your UID, who signed your binary, the program name, and a few other useful things. This lets it implement access control policies like ‘this key may be released only to version X of FooCorp’s BarApp or newer’.
The other nice thing on macOS is the notify APIs. These basically provide a 1-bit communication channel per number and let you have a small number of them in a shared page for polling and a larger number that you can use with
kqueue. These are used for kernel to userspace communication in a number of places.I don’t think that Dragonfly’s message-passing mechanism would help with either of these but I could be wrong.
One thing I really want on my Linux since Unity is a searchable global menubar. If they can get it to work in a gtk4 wayland world, I’d be extatic. Unfortunately gtk4 doesn’t seem to have a concept of a manu bar and gtk3 doesn’t expose it to dbus when running under wayland. It’s also a shame how many GUI toolkits still haven’t figure out how to expose a buffer to Wayland and still rely on XWayland to this day (Looking at you JavaFX and Chromium/Electron)
Searchable? You want a search box for the text in the UI?
Yes, that was a thing Unity did: Ubuntu called it the HUD. I hated it myself and wanted a way to turn it off. I don’t know any other desktop that ever did that.
I’m intrigued to find another of the very few people who I ever saw say that they liked it.
macOS does something similar with its global “Help” menu - selecting that (or pressing Shift+Command+?) and then typing will show matching menu items.
I’ll have to try it. This is something I’ve never even once intentionally used in >20Y on OS X.
I use it quite often in programs with sprawling menu hierarchies like Xcode, Numbers or Jetbrains.
Not sure how far along the UI side of things is, but if the project manages to build a UI framework that’s properly integrated with the rest of the OS and marginally nicer than Qt/GTK, I’d be very interested in seeing where it goes. I’m not a big fan of Obj-C or Cocoa, but at this point I just want some viable alternatives to Qt and GTK :\
My benchmark for if an OS is usable is if it can run a modern, hardware-accelerated browser. If the screenshots are up-to-date and they really have Firefox running on the new framework, that’s already a huge win. I definitely would be happy to pay for an open source nix-like OS that has a better lightweight desktop/laptop experience than what Linux currently offers. XFCE is fine, but certainly has some rough edges.