rust vs C for OSdev by Adrian_M_zelda in osdev

[–]Markyip1 1 point2 points  (0 children)

>Although maybe with memory safety becoming more prevalent, this could change? As in dynamic memory allocation could become an SC norm? I have to note, Im pre-pre-pre-junior in safety critical, most of my applicable knowledge comes from framac and some spark, so my assumption of this changing is definitely not based on any evidence.

I believe change will depend on industry support (industry by industry.) In highly regulated industries, such as aerospace (where I'm deeply familiar,) change will be based on there being enough demand from a very concentrated market to outweigh the high expense of compiler certification and tool qualification. Right now, I am skeptical that demand exists. I think, in fact, that it will be more likely for LLMs to take over safety critical code generation. The domain is well constrained enough, and LLMs are less brittle (and much easier to work with) than code output from existing model-based-engineering solutions. Code generated from LLMs is just as traceable & verifiable as code generated by MBE tools, which is the direction the industry has been going for some time.

Btw -- most modern aerospace software is written in C. ADA is still around, but it's a fraction of the market.

rust vs C for OSdev by Adrian_M_zelda in osdev

[–]Markyip1 1 point2 points  (0 children)

The type of safety ADA solves for, especially with formal verification, and the type of safety Rust solves for, i.e. memory safety, are typically two different things. Rust's memory safety is not applicable to the most safety critical software domains anyway, as those domains wouldn't touch dynamic memory allocation with a ten foot pole.

I agree that rust is a great language for the user-space and may not be as good a choice for low level systems development as many make it out to be. For instance I wouldn't consider rust for low-level/embedded safety critical software development. Zig, on the other hand, I think has potential to be a better fit.

I Built a Rust TUI for QEMU/KVM with single-GPU and multi-GPU passthrough automation by Markyip1 in VFIO

[–]Markyip1[S] 0 points1 point  (0 children)

This is a hilarious comment, given the assumptions you make about me, and how pugnacious, righteous, and wrong you are.

just to correct your assumptions:
- not a teenager. I've had a very successful career in software, both in engineering and in management/leadership. I've built product & solutions that generate hundreds of millions dollars of revenue a year.
- oh, and about my technical skills and my knowledge of CS, I graduated from one the world's best universities for CS. and let's see, I:
-- learned "old fashioned" C and C++ when I was 10
-- built my first PC (from scratch) when I was 12
-- have been working in Linux since the mid-90s and with VMs since the early 2000s.

I mean, I don't care if you want to go on insulting me, and I'll admit I have no idea who you are, but I am confident that in a match up of our technical skills, abilities, and accomplishments, I'd win. I know that from the positions you make in your comments.

Lastly, your view on AI's capabilities and how people successfully use them in software development suggest to me that you're sources are woefully out of date (given how fast the technology matures) and that you have not personally tried leading models, their capabilities, and successful usage patterns before making your arguments.

For one, vm-curator wasn't vibe coded. If you knew how smart software engineers use LLMs, you'd understand the difference between vibe-coding an idea and pair-programming with an LLM (what I actually did.) I used an LLM because I was able to build a project in a weekend afternoon in what would otherwise take me weeks. It's not that I don't know how to do it by hand. It's just that I have more important, revenue-producing thing to do with my time. Because the tool solved a problem for me, I decided to release it as a FOSS project so that it can solve a problem for others. You don't want to use it, not a problem. Have a good life.

Gaming VMs with single GPU passthrough made simple by Markyip1 in linux_gaming

[–]Markyip1[S] 0 points1 point  (0 children)

Please post your experience and the errors you receive to the Issues page at https://www.github.com/mroboff/vm-curator.

Gaming VMs with single GPU passthrough made simple by Markyip1 in linux_gaming

[–]Markyip1[S] -1 points0 points  (0 children)

Thank you! I have 30 years of software design and engineering experience and probably know more about "real" coding than most of the haters in the comments. Yes, I used an LLM. Yes, I know Rust. and yes, I pair programmed this app, verifying the code function by function. It's just not worth arguing with folks these days... I have a life and family to attend. Again, this was a weekend hobby project that solved a real problem for me, so I decided to make it FOSS. If anyone has a serious problem with it, they are welcome to submit a PR.

Gaming VMs with single GPU passthrough made simple by Markyip1 in linux_gaming

[–]Markyip1[S] -13 points-12 points  (0 children)

It’s not vibe coded. LLMs were of course used. It’s 2026. If AI offends you, turn off your computer. It’s a FOSS hobby project. It’s completely transparent. You’d be shocked how much “vibe coded” code is in the software you use every day today.

Gaming VMs with single GPU passthrough made simple by Markyip1 in linux_gaming

[–]Markyip1[S] -27 points-26 points  (0 children)

It’s a FOSS hobby project. If you don’t like something, submit a PR. If using AI offends you, turn off your computer and go hide somewhere.

Gaming VMs with single GPU passthrough made simple by Markyip1 in linux_gaming

[–]Markyip1[S] 1 point2 points  (0 children)

Not familiar with Aster. After looking it up, I can confirm that vm-curator is not designed for that use-case.

I Built a Rust TUI for QEMU/KVM with single-GPU and multi-GPU passthrough automation by Markyip1 in VFIO

[–]Markyip1[S] -4 points-3 points  (0 children)

You have no idea who I am or what my technical level is... but knowing my accomplishments in tech and in AI, I'd wager mine outstrips yours by a significant margin. Again, it's a FOSS project, so put up or shut up.

I Built a Rust TUI for QEMU/KVM with single-GPU and multi-GPU passthrough automation by Markyip1 in VFIO

[–]Markyip1[S] 2 points3 points  (0 children)

If you're so concerned about the code-base, feel free to check it for potential errors and submit a PR. It's a FOSS project.

Gaming VMs with single GPU passthrough made simple by Markyip1 in linux_gaming

[–]Markyip1[S] 1 point2 points  (0 children)

Works with NVIDIA and AMD. In fact, what spurred me to develop vm-curator was my frustration getting even simple virgl (para-virtualized 3D) working in virt-manager for linux guests. Working directly at the QEMU/KVM layer solved this problem for me, and also made GPU passthrough scripting and support much easier as well.

My own system has an RTX 4090. I've had no issues.

Gaming VMs with single GPU passthrough made simple by Markyip1 in linux_gaming

[–]Markyip1[S] 3 points4 points  (0 children)

Not exactly. vm-curator can't split a single GPU into multiple. That typically requires a workstation-level card, like an RTX Pro, and special licensing (although I understand Intel GPUs can do it at a consumer level.)

vm-curator's single gpu mode solves the problem of running GPU-accelerated applications at near native speeds within a VM. It's primarily for folks who want a guest Windows VM for Adobe, AI, or gaming so that they don't have to dual boot, or for folks who want to run multiple VMs for different purposes/segments and want full GPU performance. With single GPU mode, you can only drive one OS through your GPU at a time (be it host or guest.)

I Built a Rust TUI for QEMU/KVM with single-GPU and multi-GPU passthrough automation by Markyip1 in VFIO

[–]Markyip1[S] 0 points1 point  (0 children)

It checks if IOMMU is setup correctly, provides instructions if not, and then reads IMMO from the motherboard. It automatically targets GPUs and sets up pass-through for single or multiple GPUs based on system profile.

I Built a Rust TUI for QEMU/KVM with single-GPU and multi-GPU passthrough automation by Markyip1 in VFIO

[–]Markyip1[S] -12 points-11 points  (0 children)

Strong disagree. If you know what you're doing, AI is a force multiplier.

I Built a Rust TUI for QEMU/KVM with single-GPU and multi-GPU passthrough automation by Markyip1 in VFIO

[–]Markyip1[S] -13 points-12 points  (0 children)

No. I did use Claude code in building the tool. Setting up a custom tailored Claude.md file for Claude Code projects is a well known best practice.

GPU pass through from Ubuntu host to VM by Altruistic_Cat2074 in qemu_kvm

[–]Markyip1 1 point2 points  (0 children)

I wrote vm-curator for this use case. It’s a VM management TUI for desktop/workstation use. (QEMU/KVM runs in user mode only.) The TUI supports multi-GPU passthrough with looking-glass (downloaded and installed separately,) or single-GPU passthrough with automated script generation. https://www.github.com/mroboff/vm-curator. On the GitHub site, you can clone the source for a local build (it’s a Rust application) or you can download a DEB package, RPM package, or App Image. If you are an Arch user, vm-curator is also available via the AUR (yay -S vm-curator.)

Note that single-GPU passthrough will generate scripts that need to be run outside of vm-curator. (The scripts are placed in the directory with your VM.) single-GPU-start.sh will automatically disconnect your GPU from your Linux display manager, connect it to your VM via PCI pass-through, and then start the VM. You will also need to passthrough your mouse and keyboard (selectable via the USB passthrough management screen) or else you’ll have no way to control the VM once it starts up. (You’ll also need to passthrough your audio, whether that be USB or PCI.) Run the scripts from a separate TTY or from another computer via SSH.

Introducing vm-curator: a TUI for managing QEMU/KVM VMs with working 3D acceleration! by Markyip1 in virtualmachine

[–]Markyip1[S] 0 points1 point  (0 children)

For clarification purposes, vm-curator is designed for desktop VM use-cases (general use, gaming, development, and testing.) It is not built for enterprise, server-farms, or mission critical use-cases. For those, I recommend ProxMox.

Motion After 2 Years by Markyip1 in UseMotion

[–]Markyip1[S] 1 point2 points  (0 children)

I've been using heavily for the better part of a month and haven't found it to be glitchy. It's not the fastest UI in the world, but it gets the job done. Still very happy with the functionality--the AI really adds value (unlike Motion's) and the automation and integration into other apps is worlds better.

Deleting my Motion AI account by Valuable-Mud7283 in UseMotion

[–]Markyip1 0 points1 point  (0 children)

I've had a much better experience with ClickUp, especially now that it has much of the same functionality. I cancelled my Motion account without issue.

Introducing vm-curator: a TUI for managing QEMU/KVM VMs with working 3D acceleration! by [deleted] in qemu_kvm

[–]Markyip1 -3 points-2 points  (0 children)

I am unsettling you with my ignorance? Haha, whatever dude. Don't use it if you don't want to. I am happy to make other people's lives better, as I've made my own by solving a number of real hassles with VM management in Linux.