TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Fomos: Experimental OS, built with Rust

382 点作者 sbt567超过 1 年前

33 条评论

danhau超过 1 年前
Something I don&#x27;t like:<p>&gt; The argument that a cooperative scheduling is doomed to fail is overblown. Apps are already very much cooperative. For proof, run a version of that on your nice preemptive system: [...] Might fill your swap and crash unsaved work on other apps.<p>The difference is that in a preemptive system, a `while (true)` might slow down the system, but in a cooperative system, the machine effectively halts. Like for good. If you&#x27;re caught in a loop and don&#x27;t yield control back, you&#x27;re done.<p>In terms of security, this would make denial of service attacks against such systems trivial. You could exploit any bug in any application and it would bubble up to the entire system.<p>Or maybe I&#x27;m all wrong. I&#x27;m not an OS dev, so please someone correct me.
评论 #37320433 未加载
评论 #37323183 未加载
评论 #37320368 未加载
评论 #37322093 未加载
评论 #37320315 未加载
评论 #37328121 未加载
keyle超过 1 年前
This is so cool.<p>Particularly enjoyed:<p><pre><code> In Fomos, an app is really just a function. There is nothing else ! This is a huge claim. An executable for a Unix or Windows OS is extremely complex compared to a freestanding function. </code></pre> I can&#x27;t even begin to imagine how cool a kernel would be written this way.<p>Correct me if I&#x27;m wrong, but I think this is how smalltalk&#x2F;squeak works?<p>I hope the author continues with this project. File system, task manager, safe memory stacks, <i>nice</i> resource sharing, ...<p>... and of course, running DOOM as a minimum proof of concept requirement! &#x2F;s.
评论 #37316987 未加载
评论 #37320256 未加载
评论 #37316882 未加载
评论 #37318747 未加载
评论 #37317204 未加载
评论 #37317075 未加载
danhau超过 1 年前
Some neat ideas, but<p>&gt; As long as the OS stays compatible with the old stuff in the context, it can add new functionalities for other App by just appending to the context the new functions<p>Welcome to backwards compatibility hell. You&#x27;re boxing yourself in this way because you&#x27;re forbidding yourself to remove old &#x2F; defunct entries from the Context struct.<p>I think a better approach would be to introduce some kind of semantic versioning between OS and app. The app declares, somehow, what version of the OS it was built against or depends on. The OS then can check if the app is compatible and can pass a version of the Context struct that fits. This doesn&#x27;t get rid of most backwards compatibility problems, but you keep the Context struct clean by effectively having multiple structs in the kernel, one for each major &#x2F; minor version.
评论 #37320462 未加载
vlovich123超过 1 年前
&gt; How do you sleep, or wait asynchronously ? Just return;<p>This is a bit strange. I would think async I&#x2F;O in the style of io_uring would be fantastic but this kind of model seems to rule out anything like that. That’ll make it hard to get reasonable perf. It’s also strange to not support async as it’s a natural suspension point to hook into but you would have to give up a lot of the design where your application state has to be explicitly saved &#x2F; loaded via disk if I’m not mistaken. Seems pricy. Hopefully can be extended to support async properly.<p>In a similar vein, I suspect networking may become difficult to do (at least efficiently) for similar reasons but I’m not certain.
评论 #37320630 未加载
tayistay超过 1 年前
&gt; The argument that a cooperative scheduling is doomed to fail is overblown. Apps are already very much cooperative. For proof, run a version of that on your nice preemptive system : [pathological example which creates tons of threads and files]<p>The example is just too contrived. On a preemptive OS, apps typically hang in ways that don&#x27;t turn the whole thing cooperative (thread deadlock, infinite loop, etc.). Also, a preemptive system could kill an app if it creates too many threads, files, or uses too much RAM, long before it gets effectively cooperative. Our systems are just more permissive.<p>&gt; [Sandboxing] comes free once you accept the premises.<p>and yet<p>&gt; any app can casually check the ram of another app ^^. This is going to be a hard problem to solve.<p>So no, sandboxing doesn&#x27;t come for free.<p>That said, it&#x27;s a cool idea and I wish the author success!
评论 #37317773 未加载
评论 #37319314 未加载
duped超过 1 年前
&gt; In Fomos, an app is really just a function. There is nothing else ! This is a huge claim. An executable for a Unix or Windows OS is extremely complex compared to a freestanding function.<p>I&#x27;m curious what Fomos uses as a distinction between &quot;process&quot; and &quot;executable.&quot;<p>On Linux a &quot;process&quot; is the virtual address space (containing the argv&#x2F;envp pointers, stacks, heap, signal masks, file handle table, signal handlers, and executable memory) as with some in-kernel data (uid, gid, etc) that determine what resources it is using and what resources it is allowed to use.<p>An &quot;executable&quot; is a file that contains enough bits for a loader to populate that address space when the execve syscall is performed.<p>One of the distinctions is that you do not need an executable to make a process (eg, you can call clone3 or fork just fine and start mucking with your address space as a new process) and while the kernel uses ELF and much of the userspace uses the RTLD loader from GLIBC you don&#x27;t need to use either of these things to make a process in a given executable format.<p>And finally, a statically linked executable without position independent code is &quot;just a function&quot; in the assembler sense, with just enough metadata to tell the kernel&#x27;s loader that&#x27;s what it is. But without ASLR to actually resolve symbols at runtime, it&#x27;s vulnerable to a lot of buffer overflow attacks if the addresses of dependency functions are known (return to libc is one of those, but it&#x27;s not unique).<p>I&#x27;m the first to point out the flaws in glibc and want an alternative to the Posix model of processes (particularly in the world where the distinction between processes, threads, and fibers is really fuzzy and that is clear even within Linux and Windows at the syscall level), but I&#x27;m curious what is going on in Fomos. Most of the complexity in &quot;executables&quot; in Unix is inherent (resolving symbols at runtime is hard, but also super useful, allowing arbitrary interpreters seems annoying, but is one of the strengths of Linux over Windows and MacOS, providing the kernel interface through stable syscalls is actually the super power of Linux and a dynamic context either through libc or a vtable to do the same thing is not that great, etc).
评论 #37317159 未加载
评论 #37317816 未加载
评论 #37318485 未加载
bluetomcat超过 1 年前
How can you achieve any level of security and safety with un-trusted cooperative apps? Any app can get hold of the CPU for an indefinite amount of time, possibly stalling the kernel and other apps. There&#x27;s a reason we are using OS-es with preemptive scheduling - any misbehaving app can be interrupted without compromising the rest of the system.
评论 #37319576 未加载
评论 #37319458 未加载
tralarpa超过 1 年前
Is it actually possible to implement security in this OS without a complete redesign and basically redoing what all other existing OS have already done?<p>I am aware of two ways to enforce security for applications running on the same hardware:<p>(1) at runtime. All current platforms do this by isolating processes using virtual memory.<p>(2) at loadtime. The loader verifies that the code does not do arbitrary memory accesses. Usually enforced by only allowing bytecode with a limited instruction set (e.g., no pointer arithmetic) for a virtual machine (JVM, Smalltalk) instead of binaries containing arbitrary machine code.<p>The author of Fomos doesn&#x27;t want context switching, memory isolation, etc. And Rust compilers don&#x27;t produce bytecode. Is there another way?
评论 #37332377 未加载
评论 #37319092 未加载
评论 #37319204 未加载
doctor_eval超过 1 年前
I’m terms of cooperative multitasking I suspect this is not the same as what we had in Classic MacOS in the sense that we now have a zillion cores, so presumably one or two non yielding processes don’t actually hold the whole system up.<p>I’d also assume that a function that is misbehaved (doesn’t return) could be terminated if the system runs out of cores.<p>My point is that cooperative multitasking doesn’t necessarily equate to poor performance. Time sharing was originally a way to distribute a huge monolithic CPU among multiple users. Now that single user, multi core CPUs are ubiquitous, it’s past time that we think about other ways to use them.<p>I’m really excited that this project exists.
评论 #37319688 未加载
ilaksh超过 1 年前
Would be interested to hear the plans for security in more detail.<p>But in general I think these types of experiments show that operating systems could be improved with greenfield designs.<p>Reminds me a tiny bit of Mirage OS. <a href="https:&#x2F;&#x2F;mirage.io&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;mirage.io&#x2F;</a>
Symmetry超过 1 年前
It&#x27;s great to see a hobby OS with some interesting ideas coming out of a developer&#x27;s need to scratch their own itch, pointing to a real potential for improvement.<p>I&#x27;m not sure, but my guess is that the author might want to checkout out Barrelfish and that there might be ideas they might find worth stealing from there.<p><a href="https:&#x2F;&#x2F;barrelfish.org&#x2F;documentation.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;barrelfish.org&#x2F;documentation.html</a>
monocasa超过 1 年前
I&#x27;m not sure you can be an exokernel and cooperatively scheduled. The only thing an exokernel does enforce multiplextion boundaries on hardware resources. Yeah, it&#x27;ll be six of one in a lot of IO bound workloads, but IO bound workloads aren&#x27;t the only kind of CPU workloads.<p>And to be fair, exokernels are probably one of the least understood forms of kernel. I feel like professors&#x2F;textbooks&#x2F;papers are legally required to explain the concept poorly.
nitinreddy88超过 1 年前
Redox is full fledged OS written in rust by Pop OS developer<p><a href="https:&#x2F;&#x2F;github.com&#x2F;redox-os&#x2F;redox">https:&#x2F;&#x2F;github.com&#x2F;redox-os&#x2F;redox</a>
评论 #37319006 未加载
haspok超过 1 年前
So this is a bit like React on the OS level? Cool project, especially the cooperative scheduling part. Although I&#x27;m not sure why insist on a single function (if not for a &quot;hold my beer&quot; moment), because for any non-trivial program the single function will obviously act as the entry point of a state machine, where the state is stored in the context. I&#x27;m also not sure about redraws - is the window of a program redrawn every time the function runs?
butterisgood超过 1 年前
Hmm all apps in a single loop? Sounds like Oberon a bit. But for Rust? Neat!
jonjacky超过 1 年前
This looks very interesting, but it wasn&#x27;t clear to me how to run this, in particular, how the demo at the top of the README was run.<p>Does this repo build a standalone OS the runs on a bare machine, or does it run in a VM like QEMU, or is it a Rust application program that runs hosted on a conventional OS?
评论 #37317294 未加载
lnxg33k1超过 1 年前
It&#x27;s a cool idea, was just thinking if a program is just a function, can I just replace any function with a malicious code acting as dependency of another function? Or how would I require a specific function through signature? I guess me as a developer working on Fomos, would have to declare fully qualified dependencies in a manifest and then be able to call by function name my dependencies in my code? But then what about versioning? Do I have to bundle in my app all my dependencies? But cool idea
评论 #37317209 未加载
NooneAtAll3超过 1 年前
Can someone explain to me what FB in the Context does?<p>it&#x27;s... an array of pixels? does that imply all apps must draw themselves?
评论 #37318987 未加载
评论 #37317681 未加载
Aerbil313超过 1 年前
Theseus OS (<a href="https:&#x2F;&#x2F;www.theseus-os.com&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.theseus-os.com&#x2F;</a>) is also an OS written in Rust. It&#x27;s a safe-language OS and I believe it&#x27;s the future of the OSes due to its unique features.
评论 #37339982 未加载
sbjs超过 1 年前
Can someone explain why a bezier function is used in the mouse app? I would guess it&#x27;s to help give smoother and more natural movement to the mouse using predictions of where it&#x27;s going based on last few points, but I can&#x27;t read Rust well enough to make sure.
xpe超过 1 年前
&gt; Apps do not need a standard library, any OS functionality is given to the app through the Context.<p>Don&#x27;t <i>need</i> I can follow. But some apps will have dependencies -- some might even be tantamount to a standard library in other OSes. The Context provides all that too?
sph超过 1 年前
Finally, someone that tries non-UNIX alternative concepts with their hobby OS...
j16sdiz超过 1 年前
The &quot;sandbox&quot; is just some compile time check. As soon as you play with raw pointers, everything breaks down.<p>A good experiment, but nothing useful. Maybe the author can generate some new ideas from this.
Cloudef超过 1 年前
Now add DOM and HTML parsing and you&#x27;ll have a web browser
xialvjun超过 1 年前
So there is no &quot;kernel space and user space&quot;? Then how to protect apps, like prevent bad app read other app&#x27;s user password with pointer calculation.
评论 #37318669 未加载
评论 #37318807 未加载
评论 #37318677 未加载
Shorel超过 1 年前
This can run very efficiently in a Virtual Machine.<p>So many virtual machines run complex kernels and security features, for just one application listening on some port.<p>While this is a toy operating system for some standard Desktop scenario, it is already promising for another scenario, with the move of services to managed containers (serverless) in the cloud, with huge overhead (relative to the tasks performed) and slow startup time.<p>Then, this can be the AWS Lambda runtime for Rust (add networking and database libraries), and it will be faster and more efficient than other Lambda implementations for the other languages.
signa11超过 1 年前
from-the-page<p>&#x27;&#x27;&#x27; Exo-kernels are interesting, but it is mostly a theory. &#x27;&#x27;&#x27;<p>is that _true_ ? what is the difference between exokernel, and hypervisor ?
评论 #37322832 未加载
EspressoGPT超过 1 年前
Is it blazingly fast, though?
cozzyd超过 1 年前
Fear of missing out system?
评论 #37319792 未加载
butterisgood超过 1 年前
Does it stand for Fear Of Missing an Operating System?
ed-209超过 1 年前
&gt; Context gives any OS function necessary, ... That way, apps could be freestanding, and compatible on multiple OS<p>Really cool idea!
dainiusse超过 1 年前
Apart from KUDOS for effort, this sentence sounds best for it:<p>...you&#x27;ve got to start with the customer experience and work backwards for the technology. You can&#x27;t start with the technology and try to figure out where you&#x27;re going to try to sell it....
评论 #37320574 未加载
ericyd超过 1 年前
With no offense to the OP, I genuinely don&#x27;t understand the benefit of writing an experimental OS. Do these types of projects push the envelope in real world systems? What other benefits exist beyond a (hopefully fun) academic&#x2F;intellectual exercise?
评论 #37322081 未加载