Just to take another stab at this, but I agree with what @RandomHashTags said.
Thats been much of the discussion of this thread.
TLDR
the kernel benefits from Swift's memory safety and ergonomics
a chance to revisit kernel design with micro kernel focus
motivates the evolution of the swift language to be better in this area
interopt with C means you can do this in steps, not all at once
the userland benefits from Swift's memory safety and performance
promotes a more secure user space and application space
more performant than Dart / Flutter, Kotlin / JetPack, HTML, CSS, JavaScript
particularly performant for on device LLM inference, which could radically redefine the GUI and CLI as something new and better.
Which provides a segue to your statement:
I'm not proposing the LLM lives in the kernel, rather at the root of a modular user land
microkernels like Fuchsia OS are ideal for this
although it could be done on top of a traditional kernel like Linux, FreeBSD, XNU, etc.
LLMs are amazing pattern recognizers and soon to be basic task doers
I think they would make amazing desktop environment composers; it changes the entire app paradigm
these are on-device small LLMs, not giant potential Terminator AGI LLMs
so the issue is managing non-deterministic behavior within a modular well designed deterministic system, not total apocalypse; that's someone else's problem.
Swift's memory safety isn't free, though. That costs cycles. Same with ARC. So much of the expressivity, type-safety, and memory-safety, while completely insignificant at the application layer, would really add overhead to a kernel.
Actually, yes. I'm very worried about Swift.
It's a complete non-entity off of Apple's platforms. I know people have put work into Windows and Linux support, but that spark hasn't caught.
I see non-native frameworks like React Native as a very large threat. Especially as AI-assisted coding accelerates. As more apps move to these platforms, Apple loses controlâthey can ship new APIs and language features, but those won't matter because the common denominator of what's available is whatever these non-native platforms expose. And, critically, I think Apple vastly underestimates the threat these things pose. They're just blind to the risk.
The tooling has been left in the dust. Xcode's "AI" often suggests completely made up APIs that don't even exist. Just gibberish. By contrast, if you fire up Claude or the VSCode plugins, you get pretty useful help for other languages.
Swift's overall popularity is in decline. I'm very worried because I've invested a lot of time in it (and Apple's platforms).
Which is why I was starting with the Arch Linux kernel. I wouldn't completely rewrite the kernel in Swift, only enable native kernel support for it. Even though it could be done, the APIs and stuff aren't there yet. It can be insignificant at the application layer, but what language are you developing servers, APIs, libraries, and programs in? Are you only using a language you're being paid for? The ease of use of Swift is appealing, which is why I gave it a shot when switching from Java (for server-side and client-side). The alternatives were C, C++ or Rust. I chose 1 language for everything, and it has paid off.
True, but Apple still actively develops it. It basically runs all Apple's consumer platforms, which is obviously the right choice if you want to reach Apple's consumers (money money money). Somebody has to know Swift to reach them.
You have to write JavaScript to use React Native. You must be joking. Do you know anyone writing JavaScript servers, programs or doing AI stuff in JavaScript/TypeScript/HTML for production use?
Don't get me wrong, doing the same amount of work using one library to deploy on two operating systems and the web is a no-brainer.
I completely agree with this point. I abandoned Xcode because it is not what an IDE should be (did I mention I main Arch Linux? I do all development, including Swift, on it too). All the cool features are nice, but actually getting work done is cumbersome and not a fun experience.
Do you have any legitimate sources for your claims? Popularity is measured using different metrics for whoever is doing the measurement. The data can be skewed one way or the other and I only acknowledge objective measurements. I've seen only a few sources that are objective, and they usually put Swift in the top 5 or 10. Lets not include website, database or scripting languages and libraries in comparisons.
Additionally, just because something is more popular than another, doesn't mean it should be favored or is the better choice for the job. Why isn't the most popular desktop operating system not ran on supercomputers, smartphones or embedded devices? Why aren't developers/businesses running pure Python/JavaScript/TypeScript/HTML/CSS/Bash/SQL/Assembly servers in production?
At the end of the day you need to use languages for their use cases or become irrelevant.
Swift is the youngest language introduced in the last 10 years that is contending with the big dogs (C, C++, Java). It's not just an Apple language anymore and I am actively developing open-source Swift packages (and more planned; if you need a library, contact me or request it on the forums) to reach more use cases and helping people on these forums. If we include the last 20 years (which is barely younger than me) it would include Rust, Kotlin, TypeScript, Dart, and Go. What real options do we have for small business, embedded, hobbyists and enterprise besides C, C++, Java, or Rust to contend with everyone else?
Swift is here to stay unless Apple royally biffs it.
Yes. Just had a discussion with convex.dev a few weeks ago. I think itâs very easy to get trapped in a bubble when you develop for one platform and not see the trends happening in other areas. The sad truth is that JavaScript is winning. And itâs not particularly close.
The declining popularity claim is from the Tiobe index (which isnât perfect, but is something).
I hope Swift grows. I think itâs a fine language. But I think there are cracks in Appleâs armor that are starting to show and Swift is inexorably tied to Appleâs fortunes.
If you want to set it and forget it that's fine (working in the cloud). That's the thing about trends. They go up and down, some good, some bad. If you want to give your control to other companies (after all, they are businesses) that's your agenda.
This is more of a philosophical dilemma than following the status quo, and I see we have different values for software engineering.
By their own measurement Swift has gained 0.1% popularity over last year... ArRoW gO dOwN eQuAl BaD
Hi, I already made a suggestion to solve the problem with Models being manipulated or manipulative by giving controlled access to Interaction handles in a way that Allows for them to be effectively constrained by the system itself. This would be akin to App Intents but constrained with a baked-in permission system. Since the model would only have access to certain actions we can mitigate its effects on system integrity and protect sensitive actions. As it only sends information to these handles it can speed up learning time and it doesnât need to have access to data. I also suggested that we create little sandboxed environments for models to have their triggers to access sensitive data like your voice, video, screen, keystrokes and mouse movement. In this way we can minimize its access and control over sensitive data without sacrificing its utility.
This focus on data collection and control limitations creates a more effective and robust security mechanism than individual models being outfitted with a unique limiter that could be implemented poorly or not at all. This also allows for a more natural permission system as it allows users and apps to interact with other apps and the system.
So I was just reading the recent post from YC, and I noticed their "AI app store" has a LOT of overlap with what we've been discussing here on this thread.
For the record, its pretty important to me it stays open source, but I am not opposed to VC funding and the importance of sustainable revenue, and I tend to like the way Gary Tan, Seibel, and others at YC think. But I understand there's different considerations on the FOSS to VC spectrum.
And certainly there's risk with the swift language. It's not perfect, it drives me nuts sometimes. I don't think we have to be religious about "only swift" but I do think it's the best option right now, and there's lots of advantages by focusing on swift, as discussed above. Something like Swift first, other languages as needed, especially ones that play nice together, C, C++, Go, Python, Mojo, etc.
We want a new kind of AI App Store and OS layer that sits on your computer or phone. It should:
Protect User Data
Users control what info each app can seeâlike your calendar, files, or browsingâbut only if the user says so.
Offer One Shared Memory
All your personal details (preferences, past actions, context) stay in this layer, not scattered across a dozen apps.
Help users find the best AI apps
This App Store reviews and vets each AI tool so users can discover and install them safely.
Help Developers Build
Developers get infrastructure that help them avoid reinventing the wheel provided in simple APIs (like computer use, local LLaMA versioning, and app-level access control)
Handle Payments
Make it easy to pay for paid apps or services.
IMO funding for a project like this would not compromise the project's vision with the correct leadership. I keep more details about the OS I envision incorporating Swift to myself so I can refine them to be better when I actually get developing on this.
A finer detail I can firmly share about the OS I envision is to not lock-down (or lock-in) development to just Swift. Interoperability makes it a great starting point but not a requirement.
I would need more information about an "AI App Store". As not the biggest fan of the marketing of "AI", this doesn't sound that appealing. I'd rather use a package manager plus a UI program (kinda like an App Store) that can manage packages, programs, updates, and other related functionality.
While you can contact me on other platforms (I don't really do meetups), I see this post as one of the best ways to communicate steps forward, progress and ideas for the project.
That all sounds good to me; I'm pretty open with my ideas these days, but I can understand that.
I think a package manager / app store is the right idea, it's just the "AI apps" will look a lot different.
They'll be more like packages I think actually, they won't all need their own UI, instead just borrow system UI elements, but have custom behavior, or access to a specific domain.
I'm working on some more mockups on how at least I envision this, and will be applying to YC and see what happens. I joined your discord server and will message you there.
Well we could have the option to distribute .usmp(User Space Model Package) files which could serve a similar purpose to .app, .deb or .AppImage but instead hold the code a model needs to function like a interface, model filters, specialization trainer, data hooks and a file similar to .plist.
Specialization trainers are programs that generates a filter or modifies a filter to allow the Model to relearn or adjust its process or outputs. If the specialization trainer isnât present/enabled the model doesnât learn to do new things.
Filters are modifiers to a model as they can change weights, add/remove neurons and hold tags that determine how the modelâs response is processed.
The most complex thing would be determining a good quarantine method for the data hooks to prevent sensitive data from being accessed without permission or the function being affected by unrelated conditions. We could build a new or use an existing container manager to do this or simply use a WASM sandbox for checking if the data should be passed in to the model.
Packaging Models like this can let the OS expose your model to other areas of your system and vice versa without compromising safety while the user clearly knows what is happening. This format could also permit disabling features like data hooks and the specialization trainer.
I want to encourage plug and play as much as possible while mitigating the black box nature of models by clearly indicating what have access to and what they are able to do.
While I am interested in some security ratings for models so that we can give less technical users a indication of how safe a model is, I would want to have some more open package manager similar to atp where it is centralized but not monopolized. So a security check can be run either automatically or manually on a .usmp that does fuzzing of the code and alerts the user of highly permissive permissions so that they are properly warned about the implications of them. Opting in to permissions seems like a good bet where you choose what permissions the model can use.
I've done some initial work to outline my vision for the OS, and I will be developing a lot of what is mentioned here when I can. More information can be found at SchwiftyOS ¡ GitHub (name TBD).
Just to add to this, I consolidated my notes and wrote my own problem solution doc, on my own repo for now just for history sake, and link to schwiftyos org, we can merge ideas into the readme you created in time, but I just wanted to be extra verbose as I think about ideas on my page but not make the official readme too cluttered.
I wanted to formalize the expected structuring of a .usmp and decided on this as my goal implementation for the format. I prefer this as it is pretty clear and separated with informative section names:
Note
I donât exactly have a underlying compression/storage structure for the format as that would require a preliminary variant of the file to then inspect for how much each part uses as a whole of the file to find a better storage method
There are some secondary data formats that this bigger format needs. They are formats that could be independently implemented.
I did partially explain the secondary file formats in my initial .usmp format pitch for this project as a distribution method.
Let me know if anyone else wants to contribute as it is open-source (anyone can also make pull requests on any of the repos). I'll need to do some restructuring of the roadmap to compliment evolution proposals. Maybe down the line we could get our own category under Related Projects on the Swift Forums.
I've also had some ideas for a website for the os and another that hosts dynamic Swift products, similar to the AUR (I've some research into Swift Package Registries but don't know whether or not they are the best fit).
Once I get a central build-path for dependencies working it would be more feasible to work on bigger features (like dynamic linking and dynamic products), but I am still researching the depth required to get an accurate picture of where to begin.
Yep, let's use the SchwiftyOS ¡ GitHub org as the open source home. We can all be admins. Then I just created a Discord server SwiftOS let's coordinate communication there.
I happen to own the domain for https://swiftos.dev which we can use for the website and those ideas you mentioned.
This too is my area of focus. There's a gaping hole in tooling for edge devices especially if you don't want to rely heavily on desktop windows environment or even bloated frameworks/environments like gazebo for robotics.
@zamderax let me know when you get far and are ready to show off EDGE. It certainly sounds very interesting.
Finally made my way through this thread, which I ignored initially because such "new OS" ideas never go anywhere. However, you have some good ideas and I agree with you and the Fuchsia team that it is inevitable that the currently dominant siloed app model will be destroyed in the coming decade.
Since most of your ideas are about improving experiences at the app level, have you thought about building this as a mobile app initially? That would be the easiest way to get started, and you could always dig down to the OS level later, if needed.
It's been a year since you have been writing about this on the forum, time to find some like-minded people and build some prototypes, that you can show to early users or maybe investors, perhaps something you could try pitching on a crowd-funding site.
