Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

People throw around the ideas of VMs or WINE like it's trivial. It's really not.


On linux it's quite trivial. KVM is part of the kernel. Installing libvirt and virt-manager makes it really easy to create vms.

I'd say even passing through a GPU is not that hard these days though maybe that depends on hardware configuration more.


“On Linux it’s quite trivial…” giving big

“ or a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.”[1] vibes.

Convenience features in software are huge and even if a system is well designed a system that abstracts it all away and does it for you is easier, and most new users want that, so it often wins. Worse is better etc

[1] https://news.ycombinator.com/item?id=9224


The comment you linked is one of the most misunderstood comments on this site, which makes sense because it's one of the most cited comments on this site.

https://news.ycombinator.com/item?id=23229275

This probably isn't even the best dang comment about the situation, it's just the one I could find quickly.


Perhaps I should have put a larger explanation around it but I am mocking neither sureglymop nor BrandonM but we can still learn lessons from hindsight.

Sure, it’s trivial to set the switch in BIOS for virtualisation, and download a couple of libraries but people like computers doing things for us, we like abstractions even if they sacrifice flexibility because they facilitate whatever the real world application we are attempting.

I think power users of any technology will generally overvalue things that 80% to 95% of the user base simply don’t care about.

I admit that having touched Windows twice in the last 5 years I wouldn’t know but I would be willing to wager that WSL has very few drawbacks or shortcomings in the minds of most of its users.


Also sometimes the harder approach is also not as capable as some people make it out to be, and there are some unsolved caveats.


I don't see what's misunderstood about it, but also it's not right to make fun of the user for it.


Because it's only silly sounding because of hindsight. With today's context of file sync applications being a huge industry, that comment seems silly. But that was the prevailing opinion at the time. Check out this blog post: https://www.joelonsoftware.com/2008/05/01/architecture-astro...

>Jeez, we’ve had that forever. When did the first sync web sites start coming out? 1999? There were a million versions. xdrive, mydrive, idrive, youdrive, wealldrive for ice cream. Nobody cared then and nobody cares now, because synchronizing files is just not a killer application. I’m sorry. It seems like it should be. But it’s not.

That's just what a lot of competent people thought back then. It seems hilariously out of touch now.


But it wasn't my opinion at the time, and I didn't hear from those people. I was in middle school, kids were commonly frustrated syncing their homework to/from a flash drive, family members wanted to sync photos, and everyone wanted something like this.

Before Dropbox, the closest thing we had was "the dropbox," a default network-shared write-only folder on Mac. Of course you could port-forward to a computer at home that never sleeps, but I knew that wasn't a common solution. I started using Dropbox the same month it came out.


I'm happy for you :)


The future is rarely made by people who are comfortable with the status quo. That’s the only thing we can get from this.


His comment appears to me to say "please don't bother my friend". Him saying that file sync "wasn't common knowledge at the time"...ok? It is much easier than the solution the commenter proposed. In this thread, it's the same, people are proposing a complex solution as if it's trivial just because it is trivial to them.


Even the described FTP-based Dropbox replacement is easier than getting a VM to work properly with DRM'd software and/or GPU acceleration.


Really? With GNOME Boxes it's pretty straightforward. I hear KDE is getting an equivalent soon, too.


You can do GPU passthrough in a Gnome box, as in, your VM can see the host's GPU (let's say Nvidia) and it works exactly the same as on the host? Or another metric is if you can run Photoshop in a VM with full hardware acceleration. I haven't tried Gnome box in particular, but this isn't what I'm seeing when I search.


Ah, yeah, seems like I was mistaken and maybe Red Hat's virt-manager was what I was thinking of.

virt-manager is a bit more involved than GNOME's Boxes, I'm not sure I could recommend it to someone that doesn't know what they're doing.


Yeah, reading your original comment I was about to go off until I saw GPU pass through with DRM software. Highly cursed.


Yep, regular VMs where you basically only care about the CPU and RAM are easy, provided nothing in the VM is trying to not run in a VM. USB and network emulation used to be jagged edges, but that was fixed. VirtualBox was my go-to. It never had great GPU support, but the rest was easy.

I'm pretty sure there are solutions to assign an entire GPU to a VM, which ofc is only useful if you have multiple. But those are specialized.


Yeah! Even as a dev who can navigate vim, I absolutely don't want to do that on a daily basis. Give me pretty GUIs and some automation!


Not even close. I mentioned a software package that literally offers a full gui for all your virtualization needs.. how is that comparable to the things mentioned in that comment?


That really depends on what you want to run. Dipping into a Linux laptop lately (Mint) there are things, old things (think 1996-1999) that somehow "just work" out of box on Windows 10, but configuring them to work under WINE is a huge PITA coming with loads of caveats, workarounds and silent crashes.


The silent crashes get me. Also running one exe spawns a lot of wine/wineserver/wine-preloaded processes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: