A macOS-like operating system based on FreeBSD(github.com)
github.com
A macOS-like operating system based on FreeBSD
https://github.com/mszoek/airyx
68 comments
Lots of comments on this recently here: https://news.ycombinator.com/item?id=28068542
I saw mention of X11 and thought, "this is not for me."
macOS and Haiku are both free of X11, so I'm going to stick with those.
macOS and Haiku are both free of X11, so I'm going to stick with those.
Why is avoiding X11 better? Like X11 is mostly just an abstraction layer for drawing objects to the screen.
The extreme modular approach, while a strength in some situations is also the reason why you will never be able to build something like MacOS on any of that infrastructure.
It will always have little bits of jank, always have inconsistencies and although all it does is draw objects on a screen it just doesn't do it to the level of quality as in tear and flicker free that MacOS can manage.
It will always have little bits of jank, always have inconsistencies and although all it does is draw objects on a screen it just doesn't do it to the level of quality as in tear and flicker free that MacOS can manage.
And yet actual window management on macOS is bizarre (wtf is with the maximization behavior, that it seems each app can decide on its own) and inflexible. Tiling, snapping, alt-drag, and shading are all missing. Automation, used to emulate those features, is cumbersome, slow, and, yes— janky. (It's way more work to customize or automate window behavior on macOS than on Plasma, for example.)
Pretty much every actual window management feature on macOS aside from dragging windows by the titlebar is janky as hell. :-\
(It is neat that display server crashes/restarts on macOS don't cause you to lose your graphical session, though. Idk if any F/OSS WMs have that.)
Pretty much every actual window management feature on macOS aside from dragging windows by the titlebar is janky as hell. :-\
(It is neat that display server crashes/restarts on macOS don't cause you to lose your graphical session, though. Idk if any F/OSS WMs have that.)
Couldn't agree more. It used to be much better. I remember on Mac OS 8, the window manager made intuitive sense and got out of the way in most cases.
I don't know when it deteriorated on Mac OS X, but I've recently started to use Rectangle a lot (https://rectangleapp.com/). This has been really useful.
I don't know when it deteriorated on Mac OS X, but I've recently started to use Rectangle a lot (https://rectangleapp.com/). This has been really useful.
> wtf is with the maximization behavior
There isn't a maximise behaviour. Per the interface guidance, that button is called "zoom" [1], not maximise, and it therefore makes sense that apps do something different depending on what they need to zoom in a way that makes sense for them.
[1]: https://developer.apple.com/design/human-interface-guideline...
There isn't a maximise behaviour. Per the interface guidance, that button is called "zoom" [1], not maximise, and it therefore makes sense that apps do something different depending on what they need to zoom in a way that makes sense for them.
[1]: https://developer.apple.com/design/human-interface-guideline...
The UX discussion is not directly related to the technical discussion. Apple has its own history and more than one mode is supported. Feels to me somewhat of a legacy problem.
That said, their stability and flexibility is unmatched. Windows got a lot better recently, and they have a harder surface to deal with (orders of magnitude more hardware to support). But from an outsiders perspective Apple's feel like the best balance right now.
That said, their stability and flexibility is unmatched. Windows got a lot better recently, and they have a harder surface to deal with (orders of magnitude more hardware to support). But from an outsiders perspective Apple's feel like the best balance right now.
I almost never maximize windows and if you're someone who uses their desktop spatially like me MacOS is the only OS that manages to offer a usable and jank free version of that.
Windows and Linux just can't come close. I get why Linux never will for good reasons but Windows has absolutely no excuse.
Windows and Linux just can't come close. I get why Linux never will for good reasons but Windows has absolutely no excuse.
Ridiculous, specially considering OS X's display server is actually rooted on Display PostScript of all things.
Display Postscript got dropped after Rhapsody/MacOS X Server 1.x.
None of the 10.0+ releases of macOS used DP, instead it used Quartz2D, eventually added OpenGL to the mix, and now uses a combo of Quartz and Metal.
None of the 10.0+ releases of macOS used DP, instead it used Quartz2D, eventually added OpenGL to the mix, and now uses a combo of Quartz and Metal.
And you forget the (Quartz/Display) PDF era. The point is, the window server on OS X is about an order of magnitude more historical than that of X, so the argument above is ridiculous.
Just because it's older doesn't mean it's worse. Next had designers and a product person CEO working on it, X11 did not.
End of the day one can drag windows around smoothly and resize them without flickering and have consistent drag and drop etc and the other does not.
End of the day one can drag windows around smoothly and resize them without flickering and have consistent drag and drop etc and the other does not.
> Just because it's older doesn't mean it's worse.
No, it doesn't. But means one cannot claim "it will always have little bits of jank, always have inconsistencies although all it does is draw objects on a screen" just because it is old, since it turns out it actually isn't. X11 does have a lot of cruft, but so does WindowServer.
> End of the day one can drag windows around smoothly and resize them without flickering and have consistent drag and drop etc and the other does not.
That is just a lie. I can easily make Firefox flicker on OS X while resizing and I can easily resize say Gtk+3 windows on X without flickering. And I have almost 3 4k displays...
No, it doesn't. But means one cannot claim "it will always have little bits of jank, always have inconsistencies although all it does is draw objects on a screen" just because it is old, since it turns out it actually isn't. X11 does have a lot of cruft, but so does WindowServer.
> End of the day one can drag windows around smoothly and resize them without flickering and have consistent drag and drop etc and the other does not.
That is just a lie. I can easily make Firefox flicker on OS X while resizing and I can easily resize say Gtk+3 windows on X without flickering. And I have almost 3 4k displays...
Drag and drop isn't really a window management feature, right? It's a kind of uniform IPC for GUI apps, mostly a way to talk about files and clipboard contents (temporary files, I guess). At any rate, it has nothing to do with the display server.
That said, I do agree that I would generally expect even older Apple codebases to be less crufty than stuff like Xorg. Apple rips out legacy APIs and rewrites things pretty ruthlessly on basically every macOS release.
That said, I do agree that I would generally expect even older Apple codebases to be less crufty than stuff like Xorg. Apple rips out legacy APIs and rewrites things pretty ruthlessly on basically every macOS release.
It's a bad abstraction layer. Wayland is much better.
until you need to forward X, which I sometimes find very useful (on a LAN it's not too bad)
I used to use it over the internet in 1995. It worked nicely then.
AFAIK it worked a lot better back then because X programs sent basic drawing instructions, so messages were tiny. I'm pretty sure most of them send images over the wire now for the whole window, like VNC or what have you, thanks to all the fancy eye-candy and extra layers we've added.
That's still a stupid way of doing it. What they should be doing is caching pixmap atlases server side and sending draw requests to draw subsets of those. If they send an entire image over the wire for each frame draw, it's purely due to developer laziness.
Also, with "flat design", suddenly libXaw is on the cutting edge of UI look and feel again...
Also, with "flat design", suddenly libXaw is on the cutting edge of UI look and feel again...
Yes, they do that. But they often use Xshm to upload those pictures to the display server, and that still means sending them to the peer for server-side blitting.
Further more, by using TCP/X11 for the wire protocol, any dropped packets have to be retransmitted before you can update unrelated portions of the display because it requires in-order processing by design.
This is why high-quality, high-frame-rate remote displays never use that design.
Further more, by using TCP/X11 for the wire protocol, any dropped packets have to be retransmitted before you can update unrelated portions of the display because it requires in-order processing by design.
This is why high-quality, high-frame-rate remote displays never use that design.
You might find waypipe interesting: https://gitlab.freedesktop.org/mstoeckl/waypipe/
Nice to see someone is working on it.
Over Christmas 2017 I threw together a simple demo of a "system compositor" (a compositor that runs another wayland compositor) that sent all of the video frames rendered into a hardware video encoder (libva on an Intel GPU) as well as the screen. I was able to record playing games without much CPU overhead at all. I never really got beyond nesting the weston reference compositor because both gnome's wayland compositor and kde's kwin compositor don't support running nested (or at least didn't at the time). Was quite proud of myself for being able to record steam games playing at full screen framerate (Crypt of the Necrodancer and other simple things, I had a i7-5600u in my laptop).
I'd have probably turned it into a project like this, but I work for a streaming service professionally and they didn't approve of me working on open source work in that realm :(
Over Christmas 2017 I threw together a simple demo of a "system compositor" (a compositor that runs another wayland compositor) that sent all of the video frames rendered into a hardware video encoder (libva on an Intel GPU) as well as the screen. I was able to record playing games without much CPU overhead at all. I never really got beyond nesting the weston reference compositor because both gnome's wayland compositor and kde's kwin compositor don't support running nested (or at least didn't at the time). Was quite proud of myself for being able to record steam games playing at full screen framerate (Crypt of the Necrodancer and other simple things, I had a i7-5600u in my laptop).
I'd have probably turned it into a project like this, but I work for a streaming service professionally and they didn't approve of me working on open source work in that realm :(
Dang that sounds really cool. Such a shame you couldn’t keep working on it
How often does one need to do that though?
At ${dayjob} we do it once in a blue moon; not out of sheer necessity but for legacy reasons.
Other than that I never do it.
At ${dayjob} we do it once in a blue moon; not out of sheer necessity but for legacy reasons.
Other than that I never do it.
When you need it you need it, no matter how often.
in grad school we used it to share very powerful workstations without getting out of the office.
Sometimes I need to use a GUI program on my Desktop while I'm away. It might be something as silly as adjusting a parameter on a simulation run.
Sometimes I want to start a program on a remote computer (say VLC on my kids laptop downstairs)
Embarrassing admission - sometimes I know how to adjust a setting from the GUI and not from terminal. Maybe I want to mute a computer downstairs (btw, just an example. I'd use alsamixer, if killall weren't an option).
Honestly, I'd use it a lot more if it were faster and less laggy. Daily, even.
in grad school we used it to share very powerful workstations without getting out of the office.
Sometimes I need to use a GUI program on my Desktop while I'm away. It might be something as silly as adjusting a parameter on a simulation run.
Sometimes I want to start a program on a remote computer (say VLC on my kids laptop downstairs)
Embarrassing admission - sometimes I know how to adjust a setting from the GUI and not from terminal. Maybe I want to mute a computer downstairs (btw, just an example. I'd use alsamixer, if killall weren't an option).
Honestly, I'd use it a lot more if it were faster and less laggy. Daily, even.
I think there's a lot of potential for "run an app remotely, draw it locally". A crippled, single-application version of that's an entire, recent, highly-publicized startup, even (the controversial remote-Chrome-as-a-service company that's been posted about quite a bit in the last couple months).
I think it's not widely done because Apple and Microsoft haven't put out good tooling for it. If one of them released that kind of thing as a high-quality, polished feature, I bet it'd be big.
Also, IMO the default set-up and behavior for it on Linux machines isn't very good (shocker, that). Much better would be persistent remote sessions that let you drop your connection on one machine and re-connect on another, and leave them running indefinitely when not connected. You can get that working with some extra software but it's a bit janky and the UX is nerd-only, like most of this stuff.
I think it's not widely done because Apple and Microsoft haven't put out good tooling for it. If one of them released that kind of thing as a high-quality, polished feature, I bet it'd be big.
Also, IMO the default set-up and behavior for it on Linux machines isn't very good (shocker, that). Much better would be persistent remote sessions that let you drop your connection on one machine and re-connect on another, and leave them running indefinitely when not connected. You can get that working with some extra software but it's a bit janky and the UX is nerd-only, like most of this stuff.
>> until you need to forward X, which I sometimes find very useful (on a LAN it's not too bad)
> Other than that I never do it.
If we got rid of all the features that someone never uses (or even a lot of people never use), we wouldn't have any features anymore.
> Other than that I never do it.
If we got rid of all the features that someone never uses (or even a lot of people never use), we wouldn't have any features anymore.
it's bad if you think local single user.
if you actually use remote X capabilities, wayland is no replacement.
also it deals better if you consider apps hostile and want to still run them with some integration with the desktop but still safely isolated. X complements chroot et al much better. which I guess fits this project since this is pretty much Wine but for bsd/osx instead of linux/win
if you actually use remote X capabilities, wayland is no replacement.
also it deals better if you consider apps hostile and want to still run them with some integration with the desktop but still safely isolated. X complements chroot et al much better. which I guess fits this project since this is pretty much Wine but for bsd/osx instead of linux/win
One argument might be that X11 does not support higher than 8bit display tech AFAIK, so if you wanted to do any sort of HDR display (potentially for something like grading or some other gfx development work) you’d be out of luck.
X11 cannot handle two screens with different resolution scaling. For example.
This has been a nightmare for me. Windows has lot of trouble with mixed dpi/scaling too. The only OS that has handled this flawlessly has been macOS.
Oh yes it can; toolkits, on the other hand...
No it can not. I've seen some xrandr magic solutions but they have their own set of issues. So they are not a solution.
So it can :). I know of the issues you mention, but they are toolkit problems, since they also happen on Windows. And OS X.
The problem is, FreeBSD graphic stack is essentially the same as with Linux - same DRM drivers, same Xorg, same toolkits etc - and Wayland is still missing some functionality.
Is XQuartz substantively different than X11?
In my experience, it’s very rare having to resort to XQuartz.
XQuartz is not the primary MacOS compositor/renderer. It’s analogous to XWayland.
It's unfortunate but afaik wayland isn't fully working on FBSD, the only other choice is arcan, but nobody will ever switch to that.
There was a company back in around 2014 that had an implementation of iOS libraries for Android that they used in porting games by recompiling. I can't remember the name, and last I checked they did not seem to be in business, but maybe that could be a good starting point for some of the non-UIKit stuff.
Maybe you mean apportable? They used a lot of stuff from GnuStep and implemented a lot of UIKit with JNI Bindings to the android UI toolkit. I spend 2.5 years maintaining a game written with it. My company had a license only for this game. Any code and other things we build on top of it (mostly wrappers for native 3rd party services) went the way of the Dodo. I wrote a Xib/Nib to cocos2d Converter to load nib files and create a cocos2d scene at serialization time. I build this on top of the nib reader provided by apportable.
Facebook acquired osmeta in 2013, which built a UIKit implementation that allowed for cross-compilation of iOS apps
Sounds like Apportable: https://github.com/apportable
Our company used them for some games and other things. I once ported a UIKit app that used autolayout and was surprised at well it worked. They were acquired by Google IIRC.
Our company used them for some games and other things. I once ported a UIKit app that used autolayout and was surprised at well it worked. They were acquired by Google IIRC.
I tried the most recent ISO from the "Releases" page using Parallels, and it didn't boot (failed to find a Lua file under /boot).
Did anyone manage to try it out?
Did anyone manage to try it out?
wasnt darwin based on freebsd anyway? and didnt apple hoover up all the dev teams from Freebsd to join and built it?
> wasnt darwin based on freebsd anyway?
Darwin is more directly derived from NeXTSTEP, BSD, and Mach, though the XNU kernel includes a number of elements from FreeBSD including the network stack, and the userland is largely FreeBSD.
> and didnt apple hoover up all the dev teams from Freebsd to join and built it?
FreeBSD creator Jordan Hubbard worked for Apple 2001-2013, but I'm not sure who approached whom.
Darwin is more directly derived from NeXTSTEP, BSD, and Mach, though the XNU kernel includes a number of elements from FreeBSD including the network stack, and the userland is largely FreeBSD.
> and didnt apple hoover up all the dev teams from Freebsd to join and built it?
FreeBSD creator Jordan Hubbard worked for Apple 2001-2013, but I'm not sure who approached whom.
[deleted]
It says eventual support for MacOS apps? I'm very curious about this.
It seems like it would be a lot of work to keep up with the annual deluge of new APIs and OS features in MacOS that application developers will incorporate pretty quickly.
To really keep the promise of source-code compatibility, it seems like you'd need to quickly absorb all of the new APIs, plus, figure out how to implement them at the lower levels, on a different OS (MacOS is mach-based.)
Of course, the project has doubtless thought much more about this than I have, and maybe have an awesome plan, too.
To really keep the promise of source-code compatibility, it seems like you'd need to quickly absorb all of the new APIs, plus, figure out how to implement them at the lower levels, on a different OS (MacOS is mach-based.)
Of course, the project has doubtless thought much more about this than I have, and maybe have an awesome plan, too.
That's the part where I stopped reading... That'd be fantastic, I hope it happens. But... Wine's been going for at least 20 years, and the last time I tried, it still had major problems. Unfortunately for Wine, Microsoft keeps adding APIs. Even more unfortunately, their architectural sense leans towards "shove all the internal complexity onto the developer". I assume it is harder to re-implement a lousy architecture than an elegant one. At least Cocoa is fairly well thought out and mature. But, it's still a lot of code to write.
Just wait until they get to CoreAudio, though, hahaha! Not at all clear how that's supposed to work, and good luck if you want a sample rate that's not the default. Oh, and don't ever change anything about your environment once you've got it work, like, say, the operating system version.
Just wait until they get to CoreAudio, though, hahaha! Not at all clear how that's supposed to work, and good luck if you want a sample rate that's not the default. Oh, and don't ever change anything about your environment once you've got it work, like, say, the operating system version.
Note that Wine runs Windows binaries, whereas what this project aims for is source compatibility. That at least means you aren't at the mercy of ABI versioning, though you wouldn't be able to 'run' a macOS app you found online.
It depends on the application you're running. Wine works perfectly well for many applications and games. Just because it's not perfect doesn't mean you should stop trying.
One thing that Apple does better than Microsoft is not caring about apps using private APIs. You can use them, but you're on your own, and expect your app to break on the next major release.
From poking through the repo, it looks like it uses a FreeBSD port of Cocotron to handle Objective-C and some of the Core* APIs.
Nice goal, though I doubt it may get good traction. FreeBSD kinda sucks in hardware support. E.g. it still can't into 802.11ac. Which is a boomer for any laptop.