[DrewADesign]

>> I feel like we're back to 1990's security here.

> vibe code your own wrapper around the OS API

Maybe stick with one of the existing projects? Throwing out all of the edge cases and hardening that went into a security-related project just to burn a bunch of resources to generate a worse one you have to maintain yourself is 90s-level security with 2026-level inefficiency, IMO.

[999_cirno]

Of course, if you're not comfortable with reading or designing code, or don't feel like tinkering, you can use an existing project and they work great

But it is to note that the OS APIs do the heavy lifting, the projects are just wrappers

[DrewADesign]

Generally, assuming an RYO solution is a reasonable first approach is is a trap beginners fall into.

[pmontra]

RYO is the best way to learn, if you have the time to learn. After building one own solution one is able to assess the strengths and weaknesses of what other more experienced people built. Without the learning phase those other solutions are incomprehensible black boxes. The trick is not to skip the phase in which one researches available solutions.

[Someone]

> RYO is the best way to learn, if you have the time to learn

The problem is that nowadays, people roll their own solution, don’t take the time to learn (somewhat understandably, given the complexity of today’s stuff. You simply cannot learn all details about your hardware, OS, and third-party libraries anymore) but immediately deploy things in production.

Eating your own dog food can be good, but for security related stuff, it can easily be disastrous.

[brookst]

Honest question: is there anyone truly good at security who never made a potentially-disastrous dogfooding mistake while learning?

Not to decent mistakes or amateur brain surgery, but there has to be some level of risk tolerance among tinkerers.

[DrewADesign]

Developing software that has the sole purpose of preventing something dangerous from happening is exactly when people should strive to be engineers, not tinkerers. Beginners often don’t know the difference.

[DrewADesign]

Learning as you go is great if you’re not basing your core development workflow or data integrity on it.

[999_cirno]

Strong StackOverflow "don't do anything new, god forbid you may actually learn something" vibes

On "Hacker" News of all places :)

[DrewADesign]

Strong “I’ve never had to deal with serious security problems stemming from a weird edge case, so this all seems silly to me” vibes.

[ben_w]

> don't do anything new, god forbid you may actually learn something

vs

> vibe code your own wrapper around the OS API

[999_cirno]

In fact, I suggest reviewing the documentation to assess your own level:

https://developer.apple.com/documentation/virtualization/run...

If the below sounds too complex to work with, can review more basics first. Can start with a Swift tutorial

  virtualMachine.start(completionHandler: { (result) in
      if case let .failure(error) = result {
           fatalError("Virtual machine failed to start with \(error)")
      }
  })

[iririririr]

all community projects (specially the ones maintained or opensourced by model owners) will certainly have the security-convenience trade offs set all the way to convenience while advertising all the (off by default) security features

[DrewADesign]

Setting the convenience knob to very convenient in a system that has a lot more eyeballs on it will always be better than having something that one person who, let’s be real, probably doesn’t even have journeyman-level coding skills, estimates to be very secure based on what the model told them and a quick-skim code review.

It’s also a hell of an indictment of this community. FreeBSD is a community project. Qubes is a community project. SELinux is a community project. And people wonder why developers don’t take vibe coders seriously.