lol, as a distro package maintainer, I've literally stopped packaging and stopped using software that uses autotools. Given me meson or give me a software compiled in a respectable language, or preferably, death. I'd take cargo and its crates.io namespace warts every day over autotools, and twice on every day of the week.

Oh never stop HN. I should never use anything except 30 year old gnu tools because they've definitely never gone through development lulls, or changed ownership. Etc. "They'll still work in years", as if exa doesn't still work just fine. People here just say the stupidest shit without an ounce of consideration of how ignorant it is.

Genuine question, are there folks hyped about Deno that don't come from a nodejs background?

Me. I'm excited about what they're doing with their security stuff (I love that it can only access files that were explicitly allowed) and it feels like there's a ton of good ideas in there generally. My notes so far: https://simonwillison.net/tags/deno/

Yes.

Man, HN really just can't handle harsh truths. Do I need to go dig up 6 year old issues about this? Or the half dozen times it's come up on HN over the last 5 years?

I love Rust, I'm a big fanboy, but we need to stop pretending there aren't glaring blind spots.

>but can't possibly have a conversation about that. Nope.

What conversation? You just dropped in here with flamewar bait and complaining about some self-imagined persecution without contributing any substance. Hence your comment is now gray.

No, not lightning. If anything, it would be something like this: https://blog.gridplus.io/the-phonon-network-59835328b799

Thanks for at least offering something interesting. To be honest, the state of crypto is past what I can keep up with, but that gives me some concrete foot-holds to look into Phonon vs Lightning more.

thanks!

Don't they get tired of being wrong, too? I've used software from these types of people and their stuff crashes and segfaults as much or more than their equivalents, certainly than the rust equivalents I use.

Did you not see people warning against this previously?

These warnings are like "make backups", "use a password manager". Afaict, people are either going to, and have, or they're going to be lazy and assume it won't hurt them until it does.

Hard to trust this when the conclusion is to use NFS instead of VirtioFS. I don't buy that NFS over network, to a VM is faster than 9p, and certainly isn't faster than VirtioFS. Though "share from the VM" is good advice for NFS, since you can just reboot the guest when some part of NFS inevitably hangs (not-so-distant trauma here, including learning how to force power-off when shutdown is broken by NFS).

And yes, it works with Windows: https://virtio-fs.gitlab.io/howto-windows.html

The point I was trying to make in the article was more about reversing the direction of mounts so that instead of mounting a host directory on the guest you share a directory from the guest and mount it with a client on the host. You can achieve this using whatever – NFS, Samba, etc. This is obviously not a new concept but I find it astonishing that perhaps the majority of articles on the internet always talk about mounting a host directory on the guest which is problematic due to the reasons I covered in my article.

The main advantage of this approach is that your code resides on a native file system. This allows you to take advantage of this performance gain where it matters most, which for me is during runtime (I develop web applications and IO performance is of paramount importance). I care much, much less about performance on the host side.

Sharing VirtioFS "chroots" that live on top of ZFS is golden to simplify backup strategies & reduce bloat.. while still being able to maintain workload and network isolation.

I'm not backing up entire VMs through ZFS snapshots nor VM snapshots, and don't need a ZFS-enables backup target either. I'm merely backing up the relevant files (e.g. compose stack definitions, config files, data files) that are in the chroot, from the VM host, to GDrive, using popular tooling such as duplicacy.

Also, regarding VirtioFS: this is indeed something I have not yet tried. I’m wary of this though because this requires installing additional drivers on Windows and I usually prefer using tools that are already at my disposal (e.g. Samba on Windows).

Perhaps you should title the post "Keep your files inside your VM on a Windows host".

Not Windows specifically. I work on a macOS host so NFS works fine. However, I want to keep my options open for working on a Windows host if necessary and I wanted to keep to the toolset that already exists on the platform. I want to isolate as many responsibilities as possible inside the VM and then use a client on the host to mount the directory. Bonus points if the host already comes with this client out of the box.