> In recent years, development efforts in the OpenVMM project have primarily focused on OpenHCL (AKA: OpenVMM as a paravisor).
> As a result, not a lot of "polish" has gone into making the experience of running OpenVMM in traditional host contexts particularly "pleasant".
> This lack of polish manifests in several ways, including but not limited to: […]
> • No API or feature-set stability guarantees whatsoever.
https://github.com/microsoft/openvmm/blob/main/Guide/src/use...
> OpenHCL currently relies on Hyper-V's implementation of Virtual Trust Levels (VTLs) to implement the security boundaries necessary
Tl;Dr: Run the VM with only modern paravirtualized devices, then run OpenHCL inside the VM in ring -1 to emulate legacy devices and the guest os in ring 0 as usual.
This is more secure, as the host only exposes paravirtualized devices with reduced attack surface to the guest. While still allowing to run legacy os.
I both expect and don't expect this from Microsoft, but it makes me irrationally annoyed and I'm already feeling adversarial when reading something that does this in the first sentence no less.
I get that some people are annoyed, but can we stay on topic. As technologist we should strive to written better software, rust is a good tool for low-level components, that's it.
Could Rust, could be C# for all I care.
When it comes to low-level, security sensitive software like this, I actually do value the software being tested extensively. Bugs are bugs even if they are written in C, Rust, Ada, Elixir, Lisp or whatever language you like.
It makes me think "Ok they have made a VMM again, but this time in that somehow safer programming language Rust. They probably know what they're doing so it will be just as good as the old one, only safer!".
I know enough to know that this is not necessarily true, but when I see these posts I always hope that it's true (and rely on people with the proper knowledge and experience to verify if it is or isn't).
Then I go to the comments and there is often a discussion about how a rewrite will probably be less secure because it will introduce new bugs. But then maybe those will be fixed and eventually it will just be a more secure version.
Show HN: Comprehensive inter-process communication (IPC) toolkit in modern C++ (2024) https://news.ycombinator.com/item?id=40028118
When I see that a project is written in Rust I assume that beyond the language, their other technology/library/framework choices also tend torwards what is modern and unstable, rather than what is conventional and solid.
That information is relevant to shaping one's view of a project. I think it makes sense to mention that you're using a modern stack.
(Though Rust is already close to moving into the conventional/solid category.)
Beyond your parenthetical, what about Rust is unstable for you today? It would be interesting to me to hear that in order to see if the things that come to mind when hearing that are the same that you meant.
In practical terms and in this case it probably doesn't matter, but that is what people are talking about when they say it's both modern and unstable. It's not entirely unreasonable.
Note that "unstable" doesn't necessarily mean "broken". It just means that the ecosystem is likely to have changed massively looking back at code written today from some theoretical vantage point 5 years in the future.
yes you can write OOP in C , but please don't
and you can write fp code in Java .. this one I am not so sure about, but I would say its still better to just use scala or clojure if you must JVM, and use just use ocaml and drop the no-tail-call-optimization-jvm
the point is .. languages matter
For comparison, QEMU basically just needs glibc, glib and zlib for basic functionality.
It's very rare to see so many internal dependencies in one project, but the concept itself is well explored.
But besides that, it's just the project making use of the Rust ecosystem instead of rolling everything by themselves. From what I can see most of these external dependencies are already established in the ecosystem (some crates I am not sure since I've never used them, but anyhow, http, hyper etc. are among the most popular crates).
I don't think that's the reason, at least not the only reason. Workspaces is just a nice and modular way to organize a big project and separate concerns.
Running `cargo tree -e normal` gives a more realistic subset of what is actually used, and `cargo tree -e normal --no-default-features` gives you the "basically just needs" subset.
Another thing to keep in mind that Rust projects are very often split into many small packages (from the same authors, published as part of the same project). That isn't more code or more dependencies, but merely delivering code not as one monolith, but as modular components.
I mention Microsoft specifically because their Go projects are similarly excessive in dependencies even though higher quality Go projects do have fewer dependencies.
It's a different metric all together though, since it doesn't show transitive dependencies only direct dependencies (and as you suggest it doesn't distinguish between actual dependencies and testing dependencies because it's a workspace cargo.toml). As someone else suggested, using a program like cargo tree is the most appropriate.
It's also worth putting this in context that there's half a million lines of rust code in this repository.
I want to understand what communication channel(s) it has from guest to host. It's not clear from the cut-and-paste support described in the VNC section of the manual, how this works and what other functionality might be supported.
Time to learn.
I'd leave out the "written in Rust", because who cares, but I think it's in the license terms for Rust that you need to include that in when communication your project. The modular and cross-platform is much more interesting that the implementation language, and much more relevant for the majority of the users. I'd focus on that if I wrote the documentation and marketing material. One excuse I'd make is that the link is to the Github repository, where it's perhaps more relevant that you're informed that you'll be looking at Rust code.
So, can it run Windows 95 ?
Search HN stories for "written in", sort by date, and in the past couple weeks there are of course a number of "written in rust" but also c, python, ruby, go, c++, lisp, java, javascript, flutter, crystal, and react. Rust has the most instances currently but it's also common enough here with other languages.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
45/64.
In other words: generated more heat than light.
This is not necessarily true, you can write unsafe Rust code and you can write safe C++ code, but it does seem to hold in practice that the guardrails imposed by Rust help quite a bit in stopping devs from making really stupid mistakes.
That would be the "thrustworthiness" implied by the use of Rust.
I don't really know what a VMM consists of, so I'm mostly surprised that this project is half a million lines of code.
- Do you know your invariants?
- Have you documented them?
- If using unsafe block, have you asserted them or guaranteed that they hold for any input?
Granted, Rust is kind of mediocre at teaching you this. It raises warning for unsafe fn without safety documentation block, but not when omittin safety comments in unsafe blocks.
Edit: And it turns out it's enabled as a warning in this repo.
I haven't seen any causation between SW and their creator. A good example: Hans Reiser.
It is like talking about your car and saying that it is made of titanium and copper and composite materials while not saying anything about actual features (mileage, safety equipment).
(Or if you’ve been around super long, “written in Lisp”.)
Also, I don't find it annoying, but helpful, because I care - amongst other things - about the language of open source software projects.
Perhaps you should reconsider this. OpenVMM split up its docs and there isn't much in the actual README, but a few seconds investigation led me to https://github.com/microsoft/openvmm/blob/main/Guide/src/dev... , for example.
> Also, I don't find it annoying, but helpful, because I care - amongst other things - about the language of open source software projects.
Come on, this is not even a good strawman. It's very easy to find out the language of you want to know, and it's possible to inform without evangelism.
this is a reason to reconsider my statement why?
> Come on, this is not even a good strawman.
It's not a straw man at all. It's my opinion.
> It's very easy to find out the language of you want to know, and it's possible to inform without evangelism.
Indeed, but nothing makes it more straight forward than the language being mentioned in the HN News title
The same tokens are also used for stuff that is designed to run on bare metal/containers/kubernetes/"""serverless""".
Whenever I review a tool, or look for an alternative, I always look at the state of the maintenance and the choice of programming language, mainly to eliminate, as much as possible, the many tools written in Javascript and Python when it is not suitable.
I will not necessarily prefer a tool written in Rust, but at least it is rarely a flaw.
We tend to ascribe significance to things that are percieved as difficult, back in the day for example a book was hugely important, so authors were revered, but now with the advent of easier access to printing presses an author is not similarly revered.
Making small modules here and there, even if hard, is deemed less effort, and similarly gluing small modules together is deemed even less significant of an achievement, so what you're solving becomes much more important than how, since significance in the process is diminished.
Since Rust is harder than C++ (making compiling software is easier, even if there's runtime errors after all) - we ascribe significance to the fact that it was used.
I've been saying for years now that if Rust was a stock, I'd be investing. Meaning, if I was a young programmer I would probably take the time to learn Rust, because it's going to be in high demand.
Lisp software also presented with "Lisp" in the title. Lisp programs are rarer, so you see "Lisp" in titles less frequently than "Rust" but I believe that any Lisp program proudly claims that it was written in Lisp.
The Rust fans are pushing it a bit, I understand why they love the language, but I don't, so the insisting hammering on "written in Rust" can push me away from certain tools. In the end it will die down and the loudest will move on to the next language, once the Rust hype has been tapered out.
Rust culture is a lot like socialism, libertarians, fundamentalist religions, vegans, etc. They see themselves apart from the "mainstream", as rebels, revolutionaries, etc.
In their beginning, Java and Python were like that, too. Lua, Haskell and Kotlin also do the same. Golang is more discrete.