I'm not really sure why this project exists separately from Hello, and loath the idea that something like that is already fragmenting, Linux distro style. That said, having more things out there demonstrating that application management need not be any more complex than file management is good. It seems like people who never experienced AppDirs, Application Bundles, or the original Mac Applications simply can't conceive of a universe in which applications don't need an installer or a specialized complicated management tool.
Airyx OS
161–170 of 258 posts
Re: Airyx OS
#162Earlier quoted context omitted.
> It's a pity that she is working with FreeBSD, or it could have been of use to her. I suppose FreeBSD made more sense as a base considering MacOS is derived from BSD.
Could you perhaps relicense your implementation so it could be used outside of Linux?
I don't think it's a licencing issue. It's implementation as both kernels uses different syscalls and have different architecture.
Re: Airyx OS
#163Earlier quoted context omitted.
> source compatibility with macOS applications (i.e. you could compile a Mac application on Airyx and run it) Hard to see how this can be done legally. The libraries (sorry, Frameworks) that make up the user-space runtime for macOS are all proprietary. There's no replacement for the most important parts of it.
This is addressed in the README I linked to. Reimplementation of APIs is not legally sketchy. See Oracle vs Google. https://www.eff.org/cases/oracle-v-google https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_... .
Working second link: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_...> (it has a "." at the end)
That decision only applies in the USA. I think it will be undetermined in many jurisdictions.
Re: Airyx OS
#164Earlier quoted context omitted.
> It's just a bad idea. They'll never get even close, and those screenshots on Imgur prove it. It's a great idea. Because developing your own look and feel for the entire OS is an enormous task. This way you at least have a foundation to build upon.
It's also an enormous task to replicate one. User interface design isn't just about rounded edges and aqua chrome, it's about all of the small details: spacing, scale, padding, margins, font rendering and hinting, colour, arrangement, target zones, interactive feedback, discoverability. While I am delighted that there are people out there trying to build open source desktops that are more friendly and attractive, it…
hello started out of dissatisfaction with elementaryOS. hello tries to replicate Mac OS not how it looks but how it works. It’s not fair to compare elementary to such a new project maintained by one person.
Re: Airyx OS
#165Hm, there is a German company with the same name..
Re: Airyx OS
#166I think macOS has too large of an API nowadays to try to copy. There are a whole smorgasbord of frameworks. This can only really help with the simplest of Cocoa applications. This might be OK though, because I think what a hacker interested in this is really interested is the parts of macOS that are common with NextSTEP. Which are all the parts 20+ years old!
I checked a few files, and a lot of the foundation library have 2007 until 2009 copyright notices. Another random check, CALayer.h and CATransform3D from the Quartz framework, shows terribly limited functionality in comparison to the files on macOS 11.5. The latter comes with 198 frameworks, Airyx has 16, 2 of which don't exist (anymore). Catching up seems an impossible task.
Just look at GNUStep for a failed effort to keep up, despite it existing since the golden days of AfterStep and WindowMaker.
Does GNUStep even support latest Objective-C runtime?
Re: Airyx OS
#167Earlier quoted context omitted.
Could you perhaps relicense your implementation so it could be used outside of Linux?
I don't think it's a licencing issue. It's implementation as both kernels uses different syscalls and have different architecture.
It takes a lot of work to get the Linux GPU drivers to build for other operating systems.
Re: Airyx OS
#168Earlier quoted context omitted.
It's also an enormous task to replicate one. User interface design isn't just about rounded edges and aqua chrome, it's about all of the small details: spacing, scale, padding, margins, font rendering and hinting, colour, arrangement, target zones, interactive feedback, discoverability. While I am delighted that there are people out there trying to build open source desktops that are more friendly and attractive, it…
hello started out of dissatisfaction with elementaryOS. hello tries to replicate Mac OS not how it looks but how it works. It’s not fair to compare elementary to such a new project maintained by one person.
There's a big difference between replicating how something looks or works and replicating how something actually feels to use. Granted, elementaryOS is a more mature project with more people behind it but the attention to all those little details is what makes it feel nice to a user.
My point is that helloSystem and/or Airyx are going to need that same level of design attention if it's ever going to feel like an adequate substitute. That tends to be where most open source desktops miss the mark today — they feel like they were designed by developers, not people who understand what makes up a good user interface.
Re: Airyx OS
#169Earlier quoted context omitted.
Oh, I wasn't trying to diss FreeBSD. It would probably have been better to write my driver for fuse to make it portable, but it's too far along at this point.
Out of interest, why can't file system implementations be portable? A shared core that exists as a library that can be tested in userland, and which can then be used by a lightweight shim that implements the kernel-facing interfaces. But I haven't seen any file systems implemented this way.
While the kernel interfaces aren't exactly wildly disparate, they are perhaps surprisingly diverse (and coupled to kernel implementation details) for something as boring as a filesystem. At least some of this is for performance reasons. Accessing offsets into kernel structures is usually going to be faster than copying the data to use on your own.
On top of that, since there is no single standard interface in the kernel, kernel maintainers are skeptical of adding shims to the mainline kernel. The Linux kernel developers are perhaps the most famous for being vocal about this, but they are not unique.
That being said, there are portable file system implementations that use FUSE. See e.g. NTFS-3g[1]
Re: Airyx OS
#170Earlier quoted context omitted.
The irony is that most of the newer ones in Linux are written that way, just nobody writes a FUSE binding to them. For example, both Btrfs and XFS contain fully functional pure-userspace implementations of the filesystem inside their userspace code (libbtrfs and libxfs both contain the complete filesystem code), but nobody has written a FUSE binding to either. Btrfs' implementation is even used to do most of the func…
FUSE is neat for one-off access to obscure file systems, and FUSE is usable for things like sshfs for those who use that, but it is my impression from having used FUSE myself that FUSE does come with a noticeable performance penalty. Is my perception wrong on this? Because if it is not then I’d be hesitant to use a system where the main storage was relying on FUSE.
FUSE is also great for slower media. Copying files over USB sticks without being restrained by FAT-32 limitations is great. There have been times that I've used NTFS-3g for this because its FUSE implementation meant I could read it on any OS.