A BSD-based OS project that aims to provide source and binary compatibility with macOS® and a similar user experience. - ravynsoft/ravynos
Wine works because Microsoft spends billions on backwards compatibility and APIs are stable over time.
Apple regularly deprecates frameworks and adds new ones at rapid rates. It's a moving target with the added complication of moving build targets.
If you implement your own version of Apple's XyzKit, that might only be used in macOS 12 to 14, and not before or after that, so you put in a lot of work to essentially support binaries that were released between X date and Y date and that's it. And you have to do that for a sliding window of dates, macOS versions and framework releases and deprecations.
Wine works, because it doesn't cover many modern APIs, I would assess.
New Microsoft under Satya has a different stance on anything WinRT related, or even newer Win32/COM APIs since Windows 8.
Also .NET Framework is the Python 2 of .NET, the breaking changes are a reason there are still new projects being done in .NET Framework 4.8.x.
You can desugar all the modern stuff to windows api with first party DLLs
No, these are specifically ‘redistributables’.
In the rare case they aren’t, you just require the user to obtain it, wink and nod.
Microsoft redistributables are just the standard library. Most of the rest of the new DLLs are not backed by any system calls, just by API calls. Except of course for the D3DKMT stuff, that stuff is the real system calls used by Direct3D.
Typically in Microsoft redistributables there are terms in the license that says they can only be licensed for use with a Windows license.
Here's the Visual Studio redistributable licensing requirements:
https://visualstudio.microsoft.com/license-terms/vs2026-ga-v...
There's nothing about Windows licenses in there. There is a specious claim that I can't modify the DLL in some circumstances, but I doubt that's enforceable in any jurisdiction Microsoft could reach me, and to the careful reader the license almost admits as such.
If I'm NVidia in this case, these would be pretty easy to follow. Now I redistribute the DLL: My user downloads the DLL and uses my software (with the DLL) in Wine. Good for them. I have a happy customer. _Maybe_ Microsoft is unhappy, but I'm not sure what they can do besides pound sand: _I_ haven't violated those terms, and my user doesn't have any relationship with Microsoft.
If I've made a mistake and the Visual Studio redistributable isn't typical, what exactly do you think _is_ a typical license from Microsoft that has the force you suggest?
You are missing all the OS DLLs, COM and WinRT components, .NET libraries, that are covered by Windows EULA.
Also the ones downloaded directly via Windows Update from Microsoft servers.
That's not how copyright law works in the slightest.
You can absolutely download a file from Microsoft's website and run that file on Wine and Microsoft cannot get a judge to hold you to any "license terms" elsewhere on that website. I am not your lawyer and this is not legal advice, you are just a moron if you think otherwise.
Furthermore, I also don't think Microsoft would claim otherwise! But you are still welcome to prove me wrong by providing just _one_ example on their website of a license that you think could force me to do anything at all, because of a DLL _you_ can give to me (aka "a redistributable")
The solution for that is to decide which period do you want to build support for.
Trying to be binary-compatible with Tahoe may not be worth it. But you could make a distro binary-compatible with Snow Leopard.
Or better, make it compatible with Ventura apps without the bloat of MacOS Ventura.
That could give new life to old Macs. It can also give a PC a MacOS-like environment without having to deal with Hackintosh.
This won't work simply because majority of apps follow "the new trend". Take calibre, for example. I found myself having to OCLP my calibre server, simply because the hardware won't "take" the new macOS version required by the app, but the app new features are only available in the new versions.
I don’t think it’s as fast breaking as you suggest but certainly big changes like 32Bit support dropping, OpenGL deprecation, and move to arm64 are huge breaks.
Generally their “availability” macros in swift and objc keep things working across versions in a forward compatible way.
I've been paying attention to this project periodically over the past few years. It would be nice to have a FOSS clone of macOS, similar to how FreeDOS, ReactOS, and Haiku are FOSS clones of MS-DOS, Windows, and BeOS, respectively.
The only thing is that this project has been quite slow going, which is similar to the histories of FreeDOS, ReactOS, and Haiku, where it took a long time for those projects to get to a usable state. It is a lot of work cloning an operating system, especially with an aim for binary compatibility. The Linux kernel benefited from the fact that there was an entire GNU ecosystem of tools that can run on Unix, and even in that case, the GNU ecosystem was seven years in the making in 1991 when the first version of the Linux kernel was released. It would've taken much longer for Linux to have been developed had GNU tools not existed.
Writing an entire operating system is long, hard work, even when provided the resources of companies like Microsoft, Apple, and Google. Hopefully projects like ravynOS and the similar HelloSystem (https://hellosystem.github.io/docs/) will lead to FOSS clones of macOS eventually, even if we need to wait another 5-10 years.
Sometimes it strikes me that something like this might be one of the better litmus tests for AI — if it’s really good enough to start 10x-ing engineers (let alone replacing them) it should be more common for more projects like this should begin to accelerate to practical usability.
If not, maybe the productivity dividends are mostly shallow.
The problem is that many of these clean room reimplementations require contributors to not have seen any of the proprietary source. You can't guarantee that with ai because who knows which training data was used
> You can't guarantee that with ai because who knows which training data was used
There are no guarantees in life, but with macOS you can know it is rather unlikely any AI was trained on (recent) Apple proprietary source code – because very little of it has been leaked to the general public – and if it hasn't leaked to the general public, the odds are low any mainstream AI would have been trained on it. Now, significant portions of macOS have been open-sourced – but presumably it is okay for you to use that under its open source license – and if not, you can just compare the AI-generated code to that open source code to evaluate similarity.
It is different for Windows, because there have been numerous public leaks of Windows source code, splattered all over GitHub and other places, and so odds are high a mainstream AI has ingested that code during training (even if only by accident).
But, even for Windows – there are tools you can use to compare two code bases for evidence of copying – so you can compare the AI-generated reimplementation of Windows to the leaked Windows source code, and reject it if it looks too similar. (Is it legal to use the leaked Windows source code in that way? Ask a lawyer–is someone violating your copyright if they use your code to do due diligence to ensure they're not violating your copyright? Could be "fair use" in jurisdictions which have such a concept–although again, ask a lawyer to be sure. And see A.V. ex rel. Vanderhye v. iParadigms, L.L.C., 562 F.3d 630 (4th Cir. 2009))
In fact, I'm pretty sure there are SaaS services you can subscribe to which will do this sort of thing for you, and hence they can run the legal risk of actually possessing leaked code for comparison purposes rather than you having to do it directly. But this is another expense which an open source project might not be able to sustain.
Even for Windows – the vast majority of the leaked Windows code is >20 years old now – so if you are implementing some brand new API, odds of accidentally reusing leaked Windows code is significantly reduced.
Other options: decompile the binary, and compare the decompiled source to the AI-generated source. Or compile the AI-generated source and compare it to the Windows binary (this works best if you can use the exact same compiler, version and options as Microsoft did, or as close to the same as is manageable.)
yknow what would be funny, if a project like ReactOS or WINE relied on the Copilot Copyright Commitment[0] for protection against microsoft lawyers
[0]https://blogs.microsoft.com/on-the-issues/2023/09/07/copilot...
(though they definitely should not lol)
Are those OSes actually that strict about contributors? That’s got to be impossible to verify and I’ve only seen clean room stuff when a competitor is straight up copying another competitor and doesn’t want to get sued
ReactOS froze development to audit their code.[1] Circumstantial evidence was enough to call code not clean. WINE are strict as well. It is impossible to verify beyond all doubt of course.
We should add that the Windows source leaked, thus ReactOS had to be extra careful regarding contributions.
I’ve been thinking a long time about using AI to do binary decompilation for this exact purpose. Needless to say we’re short of a fundamental leap forward from doing that
I had never thought of this until now. Is the clean-room approach officially done with? I guess we have to wait for a case to be ruled on.
This was my thought here as well. Getting one piece of software to match another piece of software is something that agentic AI tools are really good at. Like, the one area where they are truly better than humans.
I expect that with the right testing framework setup and accessible to Claude Code or Codex, you could iterate your way to full system compatibility in a mostly automated way.
If anyone on the team is interested in doing this, I’d love to speak to them.
The organisational bottleneck still remains though. People need to discuss and coordinate at human speed.
I think AI will likely create more fragmentation initially, if a 10x developer is forced to run at 0.1x they're going to fork a project.
I believe in the AI 10x developer, but I suspect it only works for individuals or small teams at the moment.
In an actual business environment, you are right that its not a 10x gain, more like 1.5-2x. Most of my job as an engineer is gathering and understanding requirements, testing, managing expectations, making sure everyone is on the same page etc...it seems only 10-20% is writing actual code. If I do get AI to write some code, I still need to do all of these other things.
I have used it for my solo startups much more effectively, no humans to get in the way. I've used AI to replace things like designers and the like that I didn't have to hire (nor did I have the funds for that).
I can build mini AI agents with my engineering skills for simple non-engineering tasks that might otherwise need a human specialist.
There's also a cost problem here.
Who's paying $30 to run an AI agent to run a single experiment that has a 20% chance of success?
On large code-bases like this, where a lot of context gets pulled in, agents start to cost a lot very quickly, and open source projects like this are usually quite short on money.
> Who's paying $30 to run an AI agent to run a single experiment that has a 20% chance of success?
Someone who stands to make or save (significantly) more than 150$ if it's successful.
It doesn't have to be an unemployed contributer or student. Someone deploying it on a data center is the archetype you're looking for.
I have the unpopular opinion that like I have witness in person the transition from Assembly into high level languages, eventually many tasks that we manually write programs for, will be done with programable agents of some sort.
In an AI driven OS, there will be less need for bare bones "classical" programming, other than the AI infrastructure.
Now is this possible today, not really as the misteps from Google, Apple and Microsoft are showing, however eventually we might be there with a different programming paradigm.
Having LLMs generate code is a transition step, just like we run to Compiler Explorer to validate how good the compiler optimizer happens to be.
Sure. In the meantime productivity is still useful.
> A BSD-based OS project that aims to provide source and binary compatibility with macOS® and a similar user experience.
I am curious - what is the motivation for this project?
Is it to replicate macOS? - If yes, why?
Is it to provide application compatibility on a non-macOS? If yes, why a full OS? Why not take the route like Wine or other such layers that make compatibility possible? Also, is there such a need for running macOS apps on a non-macOS? Who is the target audience?
Would the energy be better spent in making Linux more stable or usable for the general public?
If its just a hobby, sure, that is well & good.
A lot of these questions are answered here: https://ravynos.com/faq
To summarize...
There is a WINE-analogous project, called Darling: https://www.darlinghq.org/
The goal for ravynOS is to be analogous to ReactOS. Much like ReactOS and WINE, ravynOS and Darling share a lot of Cocoa code.
For the problem of OpenStep implementations specifically, a bespoke software stack has the benefit of being able to put Mach messaging into the kernel, where it is much more performant.
They chose the FreeBSD kernel over Darwin for the sake of hardware compatibility (though of course NeXT Mach is one of the most widely-ported kernels of all time...)
There is also overlap with GNUstep, helloSystem, and other projects in the broader "open-source Mac/NeXT" space, though ravynOS (obviously) prefers BSD/MIT/Apache-style licensing over GNU-style licensing. Nevertheless, ravynOS currently uses the GNUstep libobjc2 runtime, a bit like how most of the Unix world used to depend on gcc.
> There is a WINE-analogous project, called Darling: https://www.darlinghq.org/
Missed opportunity to call it Cider.
There's already been a Cider; it used some Wine code to ease porting games to MacOS.
For reasons that I do not understand, the company behind Cider pivoted to real estate investing, and got out of the tech field entirely
Hard Cider
They had chosen a FreeBSD base. The most recent forum posts suggest throwing away most of the FreeBSD base and going with Mach-o. That actually makes their goals of getting to macOS compatibility a bit simpler but it’s less interesting to me.
> of course NeXT Mach is one of the most widely-ported kernels of all time...
actually the broader Mach kernel, not specifically the NeXT variant, is the one with a documented history of extensive portability
The NeXT variant did run on the following architectures:
1. Motorola 68k (the original NeXT hardware had 68030 and 68040 chips)
2. Intel x86 (NeXTSTEP 3.1 for Intel was released in 1993)
3. HP PA-RISC (I have an OPENSTEP 4.2 CD that can run on Motorola 68k, x86, PA-RISC, and SPARC hardware)
4. Sun SPARC
5. 32-bit PowerPC (Rhapsody, the original Mac OS X 1.0 that was essentially still Rhapsody, and of course Mac OS X from Cheetah through Leopard)
6. 64-bit PowerPC (Power Mac G5 and iMac G5)
7. Intel x86-64 (starting from Mac OS X Tiger all the way to macOS Tahoe)
8. 32-bit ARM (iOS on early iPhones with 32-bit ARM chips)
9. 64-bit ARM
I could be forgetting other platforms, but these are the ones I know from the top of my head.
Indeed—I meant specifically the NeXT branch of the family tree because of this exhaustingly long list.
I would very much like to see that quad-fat OS4.2 CD; most NeXT releases around that era drop PA-RISC and are only tri-fat. I only have a 3.3 RISC (HPPA+SPARC) ISO for HPPA coverage.
The big ones you're missing are the Intel i860 (used as a graphics accelerator on NeXTdimension video processing boards—also the original target platform for the Win NT kernel) and the Motorola 88k family, which was briefly explored for the "NeXT RISC machine" in the mid-90s; only one prototype is known to exist. There were non-NeXT ports of Mach to m88k, which may have influenced the decision.
Of course, if we add in the other branches of the Mach family the number of ports gets absurd! It originated on the VAX; OSF/1 adds MIPS and AXP to the list... ultimately RISC-V and Itanium are the only significant ≥32-bit CPUs of the last forty years to not see some kind of Mach port.
But—the ultimate point is that the lion's share of actual work porting the kernel to new hardware is thanks to NeXT and/or NeXT cosplaying as Apple.
I'm not affiliated with ravynOS, but I've been periodically following the project for a few years.
The main page (https://ravynos.com/) expresses the philosophy of ravynOS:
"We love macOS, but we’re not a fan of the ever-closing hardware and ecosystem. So, we are creating ravynOS — an OS aimed to provide the finesse of macOS with the freedom of FreeBSD."
rayvnOS seems to be designed for people who love macOS, particularly its interface, its UI guidelines, and its ecosystem of applications, but who do not like the direction that Apple has moved toward under Tim Cook (soldered RAM, limited and inflexible hardware choices, notarization, iOS-influenced interface changes, increased pushiness with advertising Apple's subscription services, etc.) and who would be unhappy with either Windows or the Linux desktop.
Speaking for myself, I used to daily-drive Macs from 2006 through 2021, but I now daily-drive PCs running Windows due primarily to the lack of upgradable RAM in ARM Macs. I'm not a big fan of Windows, but I need some proprietary software packages such as Microsoft Office. This makes switching to desktop Linux difficult.
It would be awesome using what is essentially a community-driven clone of macOS, where I could continue using a Mac-like operating system without needing to worry about Apple's future directions.
On the Unix side of things, I believe the decision to base ravynOS on FreeBSD rather than on Linux may make migrating from macOS to ravynOS easier, since macOS is based on a hybrid Mach/BSD kernel, and since many of the command-line tools that ship with macOS are from the BSDs. This is known as Darwin. It's not that a Mac clone can't be built on top of Linux, but FreeBSD is closer to Darwin than Linux is.
> soldered RAM
Hold on a minute.
It's not "soldered". It's integrated with the SoC. The benefit is memory latency and bandwidth.
If you know Framework, their entire mission is to build upgradeable laptops, and they keep delivering. Now they also wanted to build an incredibly powerful, but small and quiet desktop. They went directly to AMD, asked their engineers to make the memory upgradeable. AMD worked really hard and said not possible, not unless you want all of these cores to sit idle.
https://frame.work/blog/framework-desktop-deep-dive-ryzen-ai...
The world has moved on. Just as you no longer have discrete cache chips or discrete FPUs, you can't do discrete memory anymore - unless you don't need that level of performance, in which case CAMM is still an excellent choice.
But that's not what Apple does. M1 redefined the low-end. It will remain a great choice in 5 years, even when macOS kills it off - Asahi remains very decent.
no, they are talking about high performance desktops, mostly. They link to the Framework desktop, which has 256 GB/s memory bandwith. For comparison, the Apple Mac Pro has 800 GB/s memory bandwidth. Neither manufacturer is able to achieve these speeds using socketed memory.
> no, they are talking about high performance desktops
then i don't really get the "world has moved on"-claim. in my bubble socketed RAM is still the way to-go, be it for gaming or graphics work. of course Apple-user will use a Mac Pro, but saying that the world has moved on when it's about high-performance, deluxe edge-cases is a bit hyperbolic.
but maybe my POV is very outdated or whatever, not sure.
I think, but am not totally positive, this is primarily a concern for local LLM hardware. There are probably other niches, but I don't it's something most people need or would noticeably benefit from.
So somehow running MacOS in 2025 on hot, loud, horrible battery life x86 based computers is a good thing?
Not to mention x86 Mac apps are not long for this world. I can’t think of a single application I would miss moving from Macs to Windows. It’s more about the hardware and the integration with the rest of my Apple devices.
Notes and Reminders are extremely good at what they do, and the synchronization with their iOS equivalents is flawless from what I can tell… and fat chance you get to uproot such a thing to a non-Apple OS.
Third party apps other than for media editing seem to be rare, I think Apple has gobbled or rug pulled much of its independent software vendor ecosystem.
Come to think of it, it just dawned on me that most of the proprietary Mac programs I’ve used on Mac OS X/macOS (as opposed to the classic Mac OS) are either from Apple (Preview.app, Dictionary.app, iPhoto/Photos, iTunes/Apple Music, Keynote, iMovie, GarageBand), Microsoft (Office, Teams), or are Electron apps like Zoom and Slack. The only non-Microsoft, non-Electron third-party proprietary applications I’ve used on my Macs in the past 19 years are from the Omni Group, particularly OmniOutliner (which came bundled with my 2006 MacBook) and OmniGraffle.
It seems that what I miss the most about using a Mac whenever I’m on Windows or Linux is Apple’s bundled apps, not necessarily third-party Mac apps since I never used them much to begin with. Makes me think harder.
Apple Mail also is in my eyes the only generic mail client out there that really “gets it”.
Thunderbird has always felt clunky in comparison and the recent redesign just made it a different kind of clunky. Everything else is either too minimal (Geary), tries to clone old style Outlook (Evolution), or is tied to/favors a particular provider (Gmail, Outlook, etc).
This. I use Linux as my primary OS (with KDE) and my main complaint, by far, is the email/calendar situation. Mail.app simultaneously just works and gets out of my way, and I haven't seen a Linux email client come close to replicating that.
Every few years I convince myself I'll create a better email client for Linux, and I always start the project enthusiastically and stop soon after, when I get just far enough to be reminded of how complicated email is. Maybe someday I'll take a sabatical and actually do it...
> I always start the project enthusiastically and stop soon after, when I get just far enough to be reminded of how complicated email is.
What are some of the things you’re thinking of?
Is there a reason you cannot clone an existing client with technically solid mail handling and build a new UI on top of it?
That’s what I was implying when I said the integration.
As far as indie apps, BBEdit will survive the heat death of the universe and has made it through every Apple transition since at least System 7 in 1992.
Funny enough, I’ve only had one Apple computer during each era - an Apple //e (65C02), a Mac LC II (68K), A PowerMac 6100/60 (classic Mac PPC), Mac Mini G4 (OS X PPC), a Core Dúo Mac Mini (x86) and now a MacBook M2 Air.
I was never really that interested in x86 Macs and I just bought cheso Windows PCs that I really didn’t use that much outside of work except web browsing and back in the day iTunes.
> BBEdit will survive the heat death of the universe
With GraphicConverter by its side.
This description really resonates with me, so I guess I’m a potential user.
I’ve been running macOS most of my life. In college I ran Linux on my laptops, but I switched back to macOS as the user experience was better - I could spend far less time messing with things and instead rely on system defaults and first party apps.
Year by year though I feel more like I don’t own my computer. I’ve tried switching back to Linux, but I always give up because despite the freedom, it starts feeling like a chore. Even Asahi Linux on macOS hardware I couldn’t get into.
The rayvnOS vision is something I could get behind. A fully packaged, macOS-like user experience, where the default settings are good and things work out of the box. I’d LOVE to have that as on option.
Linux compatibility or even macOS binary compatibility matters less to me than, say, an out of the box Time Machine like backup tool based on ZFS snapshots. So FreeBSD makes sense from that perspective.
I guess drivers are important, which is a good reason for choosing FreeBSD :)
It's a shame that OpenDarwin didn't continue. PureDarwin seems to exist, but progress is understandably slow.
> Also, is there such a need for running macOS apps on a non-macOS?
Arguably there's a need for running macOS apps on macOS even. E.g. my parents are stuck having an old Intel Mac Pro around on an old OS for a few 32-bit programs (not sure if it changed, but IIRC you couldn't run an OS that supported them as a VM on Apple Silicon). Pretty soon Rosetta 2 will go away as well.
I have the same sentiment. I am forced to use a MacBook in my new job while waiting for them to procure a laptop that I can put Linux on. I can say that Linux with KDE Plasma desktop is in almost every way superior to Mac OS. Much better UX, configurability and core applications. And even little things are more polished and thought through compared to what a trillion dollar company was able to produce. It's really beyond me how people use Apple products, and it's the absolute majority of them in my field.
“Better” is largely subjective. For some (including myself), a Windows-like paradigm like KDE uses is not desirable, and UI papercuts like the many that KDE has are highly visible.
I use KDE because it lets me emulate a macOS-like paradigm better than Gnome or other options can.
Tried it for a while, it was death by a thousand papercuts.
I wanted the Konsole theme to stay in sync with system light/dark theme. I ended up writing a pair of .desktop files and a helper program to talk to DBus.
I want to use my computer, not configure it.
I don't keep the record of every thing that I don't like about MacOS, but here's some:
- cannot keep natural scrolling for trackpad whilst having the expected scrolling behaviour for the mouse
- needs an external app for fractional display scaling
- screenshot tool is objectively inferior to that in Plasma, eg. not clear how to annotate a screenshot or copy it to clipboard
- Dolphin file browser is has cleaner and simpler UI, is more configurable and has a built-in terminal which is super handy.
...
Can’t comment on the others but I copy screenshots to the clipboard multiple times a day in macOS and have done for years. Very frequently I send them via Screen Sharing to another Mac and paste there, something I value hugely.
macOS has markup tools for screenshots (or any image) built right into Quicklook and Preview. It’s not as rich as something like SnagIt, but it’s good enough for adding some text, arrows, shapes, redactions, etc.
Dolphin is one of the things about KDE that bothers me, due to the way its windows are laid out and how they use margins/spacing. It just feels “wrong” in a way that even most other Linux file managers (including more full featured ones that still have a menubar) don’t.
> - screenshot tool is objectively inferior to that in Plasma, eg. not clear how to annotate a screenshot or copy it to clipboard
I'm not sure what to make of this. When you take a screenshot (i.e. via cmd-shift-3 or cmd-shift-4), right there in the window that pops up are the annotation tools and a button to copy to clipboard?
You can also screenshot directly to the clipboard by adding control to the keyboard shortcut (e.g. control-shift-command-3).
> needs an external app for fractional display scaling
Huh? I go to Settings -> Displays -> Advanced -> Show resolutions as list -> Show all resolutions -> you can literally pick *whatever* your screen will advertise?
*Maybe* that's one or two clicks too many? Arguably you don't want non-technical users to accidentally set up blurry text.
There are objective criteria that macOS definitely fails at. Various government agencies here in the states can't use macs even if they wanted to due to lack of #a11y support or the ability to load their own root cert stores.
I agree with you that for MOST people, MOST of the complaints boil down to "I just don't like the Mac UX," but there are organizations that cannot tolerate the risk of forcing employees to use equipment that doesn't follow even the basics of section 508 or DoD guidance.
That is a quite strange reason, as Mac and iOS have by far the most investment in accessibility of any system. The amount of accessibility features both systems have is bewildering.
Every company using Macs I’ve ever worked for has MDM and their own root certs, that’s basic device management. Are you thinking of something else?
What accessibility is it missing?
You can't install roots for all apps, notably the app store. Various government agencies occasionally like to install apps that are not web apps.
I'm not sure I understand. What software do they expect to install via the App Store that can't be installed with the Apple's root certificates? Apple signs everything listed on the App Store, does it not?
Also, why would they need the App Store to distribute software signed by their own keys anyway?
Yes.
Lucky, here Linux lives on servers, or desktop VMs.
Except for the trackpad, alas.
Just curious... did your employer agree to getting you a Lennucks Bocks 'cause you asked nice or were they frightened of running afoul of one of the many #a11y or security evaluation frameworks?
You keep mentioning that in this thread, but a11y on a Mac is considered the gold standard.
Security on a Mac, the same (SIP, Keychain, Secure Enclave, great tools for fleet management)
What specifically is in violation of "#a11y or security evaluation frameworks"?
It would be great if it runs on mac too. macOS doesn't have much compatibility with itself.
> Would the energy be better spent in making Linux more stable or usable for the general public?
Linux is stable and widely used, whether as Android, Ubuntu, WSL on Windows or Crostini on ChromeOS (itself Linux under the hood).
The general public buy products like Macs, Lenovos, Steam Decks, Chromebooks or Frameworks. Nobody buys a "Linux".
Linux and it's ecosystem are features of those products, not products themselves.
Obviously the idea was about a Linux desktop - whether that means investment in toolkits like Gnome, KDE, core infra like X11 or Wayland, or distributions like Debian.
Yes, but Linux's desktop environment(s) is a feature of a product, not a product itself. You can see that Framework themselves markets Linux that way: https://frame.work/linux
If the goal is to make the Linux desktop more popular with the general public as the previous comment suggested, then you must create a product built exclusively around it that is marketed to the general public. There doesn't seem to be much interest in this
I would much rather emulate linux apps on a more stable and consistent OS than vice versa. The sheer number of toolkits and window managers leaves my head spinning, and unifying their behavior even before you can begin to improve it feels like a nightmare.
I personally don't care much about the dock or the look and feel or whatever; I just want access to the usability of macos without having to accept how closed it is.
It's hard to get a more consistent and stable kernel than Linux, not counting academic or experimental kernels w/o extensive hardware support.
I'm not referring to the kernel at all. It's the morass of the userland—three decades of catering to the expectations of IBM PC/windows users have led to... inconsistent and underwhelming results. If I wanted to use 1980s UX, I would have switched to windows or linux decades ago.
But what am I saying? Consistent emacs bindings across all text forms is actually from the 1970s. Maybe I'm the problem....
If it is no longer closed, it might proliferate just like Linux once it gathers a critical amount of users. :)
Mac OS without the background ads garbage or the constant blocking of call-home requests would be nice.
Spelled windows wrong
Where are you seeing ads?
Maps, news, stocks are all installed by default and supported by ads. Opting out eliminates personalization. One needs to install an app like lulu to block background calls even with personalization turned off. This started with the twitter integration many years again and while social is no longer tightly integrated, the philosophy around user fingerprinting “while not being tied to your identity” is still very much alive and well in a default macOS install.
That’s all ad-supported shovelware. I use a Mac all day long for work. I never use Maps, News, or Stocks. I also don’t use Weather, Music, Mail, Pages, Numbers, FaceTime, Keynotes, Contacts, Reminders, Photo Booth, Books, Dictionary, Stickies, Voice Memos, AppleTV, GarageBand, or Image Playground.
I do use Preview quite a bit. I sometimes use TextEdit, Terminal, or Safari, but I more often use Vim, iTerm2, Firefox, DuckDuckGo Browser, or sometimes Chrome.
It helps not to judge a whole OS by three free apps included with it. Microsoft meanwhile puts ads in the main menu and in the task bar. I wouldn’t be surprised if the Windows desktop wallpaper on the Home editions become ads.
There aren't any ads in Maps - at least, not yet.
what are you smoking ?