4 ms·

>FreeBSD Does Not Support Virtualisation this is a half-answer at best and not really relevant. the point of virtualization is that the OS doesnt really care

>FreeBSD Does Not Support Virtualisation this is a half-answer at best and not really relevant. the point of virtualization is that the OS doesnt really care or know its being virtualized in the first place. supporting the virtualization of BSD is a moot point as it really doesnt concern the OS. bhyve (for all its worth currently) isnt mentioned, but it would be nice to see peoples experiences with it to date. props for not flogging jails as a solution however, as quite a few BSD purists will cheerlead this as virtualization. >The BSD License Means Companies Don't Contribute Back the real issue here is with license purists and the philosophy of open source. BSD gifts companies with an easier path to turning your work into a cloistered and proprietary part of their code, whereas GPL at least makes an effort to keep them honest about their appropriations. plenty of companies to date still do skirt the GPL though. ultimately whether or not a company gives back to an OS community is a matter of business prerogative and not entirely license.

jedberg 5y ago
For a long time FreeBSD did not work on EC2 or in Virtualbox, which is where this comes from and why it's relevant.
- kelp 5y ago
  And now I have FreeBSD 14 (13 won't boot and the issue is only fixed in -current) running in Parallels on my Apple Silicon MacBook Pro... works well.
  - drewg123 5y ago
    Is the VM running arm64 or amd64?
    - kelp 5y ago
      arm64 Otherwise it would be emulation not virtualization. Parallels on Apple Silicon only works with arm64 VMs. But that's pretty much everything I care about. I have Windows 11, FreeBSD, OpenBSD, several Linux distributions. They all work fine.
      - drewg123 5y ago
        I thought M1 silicon could run amd64/x86_64 efficiently via Rosetta, due to changing the memory ordering model to an x86 one. I was hoping that Parallels could somehow take advantage of that.
        kelp 5y ago
        Yeah I don’t think it can do that, unfortunately.
Cyberdog 5y ago
> bhyve (for all its worth currently) isnt mentioned, but it would be nice to see peoples experiences with it to date. props for not flogging jails as a solution however, as quite a few BSD purists will cheerlead this as virtualization. I don't think you read the article very well. It mentions bhyve and also promotes jails - which I think are a perfectly acceptable solution to many (but not all) of the reasons why someone might want to do virtualization - I've moved on to OpenBSD for my hosting and have also been experimenting with NetBSD, but in both of them I'm really missing something equivalent to FreeBSD's jails and I wish the idea had caught on in the broader BSD ecosystem.
kelp 5y ago
This is hardly a production use case, but I've had a bare metal server at OVH for several years. It's currently running FreeBSD 13 with bhyve. I have about 4x VMs running on it, including OpenBSD and several different Linux flavors. Things have just worked and I've really not had any issues with it in the years it's run. The VMs are stored on a mirrored zfs zpool with sparse volumes so they only take up space they actually need. All that said, I find the bhyve config language and command line options to be pretty painful, so I've been only using it with this frontend: https://github.com/churchers/vm-bhyve https://github.com/churchers/vm-bhyve
gwd 5y ago
> >The BSD License Means Companies Don't Contribute Back > the real issue here is with license purists and the philosophy of open source. BSD gifts companies with an easier path to turning your work into a cloistered and proprietary part of their code, whereas GPL at least makes an effort to keep them honest about their appropriations. plenty of companies to date still do skirt the GPL though. ultimately whether or not a company gives back to an OS community is a matter of business prerogative and not entirely license. But there's a difference between "giving back to the community" and "releasing your changes under the GPL". The only actual requirement is that the modified source code be 1) made available to the people to whom you give binaries, and 2) it be licensed GPL. There is no requirement even to send the code to the upstream project; and there's certainly no requirement to engage with the maintainer / review process to get the new code into suitable shape that the upstream project actually wants to take it. Without engaging with the maintainers of the upstream project, there is virtually no chance that anything other than trivial patches will be in an upstreamable state in the vendor's patchqueue; and so virtually no chance that someone receiving the GPL'd patches could actually apply them upstream without doing a significant amount of work to make them so. I know of very few cases where people have the appetite to that sort of work. So the result is that, in practice, companies contribute back to GPL-licensed projects for the same reason they contribute back to BSD-licensed projects: because they want to be able to pull in new code from the upstream, and having to rebase a patchqueue every time they want new upstream features is more expensive than engaging with the maintainers to contribute their own code back. The main difference is in the small cases where there is enough community interest to actually take a company's internal patches and do the work of cleaning them up to get them upstream.
- EricE 5y ago
  >The main difference is in the small cases where there is enough community interest to actually take a company's internal patches and do the work of cleaning them up to get them upstream. Exactly. It's also why the argument that open source has an advantage because many eyes can look at the code is also a mostly empty promise, and why things like Heartbeat happened despite everyone knowing the criticality of code like OpenSSL being absolutely solid. If you don't have enough of the right people looking at the right code then you get things like Heartbeat. I'm not pointing this out to argue that Open Source is worthless, but rather to encourage people to not get complacent - Open Source is not a panacea and should still be vetted as you would vet any other part of your solution. >So the result is that, in practice, companies contribute back to GPL-licensed projects for the same reason they contribute back to BSD-licensed projects: because they want to be able to pull in new code from the upstream, and having to rebase a patchqueue every time they want new upstream features is more expensive than engaging with the maintainers to contribute their own code back. You mean people act in favor of their own enlightened self interests? Who could have guess that? Ham fisted attempts to force people to do the right "moral" thing rarely succeed. But we have people who insist "if we just had a better policy!". Sigh. Think of how much more productive we could collectively be if we stopped worrying about how to control other people, but instead structure our approaches to influence their inherent behaviors to get the better outcome naturally? And if they still go their own way shrug and go on? The GPL has evolved into a beast that would make the most aggressive HOA blush - yet the same people who would rightly go after a busybody HOA have no problem cheering misguided efforts like GPL 3 on? It's pretty amazing.
flykespice 5y ago
> BSD gifts companies with an easier path to turning your work into a cloistered and proprietary part of their code Actually, BSD might incentivize "proprietary" companies more than GPL to contribute back to upstream. Even ignoring the gratitude factor for BSD license granting more freedom than GPL, it's just strategic. Companies want to apply their own local patches to the kernel whilst keeping update to upstream changes, it becomes a burden, specially if the infrastructure where the patch touches changes, to ease the burden of maintaining the patches they contribute them to upstream.

jedberg 5y ago

For a long time FreeBSD did not work on EC2 or in Virtualbox, which is where this comes from and why it's relevant.

kelp 5y ago
And now I have FreeBSD 14 (13 won't boot and the issue is only fixed in -current) running in Parallels on my Apple Silicon MacBook Pro... works well.
- drewg123 5y ago
  Is the VM running arm64 or amd64?
  - kelp 5y ago
    arm64 Otherwise it would be emulation not virtualization. Parallels on Apple Silicon only works with arm64 VMs. But that's pretty much everything I care about. I have Windows 11, FreeBSD, OpenBSD, several Linux distributions. They all work fine.
    - drewg123 5y ago
      I thought M1 silicon could run amd64/x86_64 efficiently via Rosetta, due to changing the memory ordering model to an x86 one. I was hoping that Parallels could somehow take advantage of that.
      - kelp 5y ago
        Yeah I don’t think it can do that, unfortunately.

Cyberdog 5y ago

> bhyve (for all its worth currently) isnt mentioned, but it would be nice to see peoples experiences with it to date. props for not flogging jails as a solution however, as quite a few BSD purists will cheerlead this as virtualization. I don't think you read the article very well. It mentions bhyve and also promotes jails - which I think are a perfectly acceptable solution to many (but not all) of the reasons why someone might want to do virtualization - I've moved on to OpenBSD for my hosting and have also been experimenting with NetBSD, but in both of them I'm really missing something equivalent to FreeBSD's jails and I wish the idea had caught on in the broader BSD ecosystem.

kelp 5y ago

This is hardly a production use case, but I've had a bare metal server at OVH for several years. It's currently running FreeBSD 13 with bhyve. I have about 4x VMs running on it, including OpenBSD and several different Linux flavors. Things have just worked and I've really not had any issues with it in the years it's run. The VMs are stored on a mirrored zfs zpool with sparse volumes so they only take up space they actually need. All that said, I find the bhyve config language and command line options to be pretty painful, so I've been only using it with this frontend: https://github.com/churchers/vm-bhyve https://github.com/churchers/vm-bhyve

gwd 5y ago

> >The BSD License Means Companies Don't Contribute Back > the real issue here is with license purists and the philosophy of open source. BSD gifts companies with an easier path to turning your work into a cloistered and proprietary part of their code, whereas GPL at least makes an effort to keep them honest about their appropriations. plenty of companies to date still do skirt the GPL though. ultimately whether or not a company gives back to an OS community is a matter of business prerogative and not entirely license. But there's a difference between "giving back to the community" and "releasing your changes under the GPL". The only actual requirement is that the modified source code be 1) made available to the people to whom you give binaries, and 2) it be licensed GPL. There is no requirement even to send the code to the upstream project; and there's certainly no requirement to engage with the maintainer / review process to get the new code into suitable shape that the upstream project actually wants to take it. Without engaging with the maintainers of the upstream project, there is virtually no chance that anything other than trivial patches will be in an upstreamable state in the vendor's patchqueue; and so virtually no chance that someone receiving the GPL'd patches could actually apply them upstream without doing a significant amount of work to make them so. I know of very few cases where people have the appetite to that sort of work. So the result is that, in practice, companies contribute back to GPL-licensed projects for the same reason they contribute back to BSD-licensed projects: because they want to be able to pull in new code from the upstream, and having to rebase a patchqueue every time they want new upstream features is more expensive than engaging with the maintainers to contribute their own code back. The main difference is in the small cases where there is enough community interest to actually take a company's internal patches and do the work of cleaning them up to get them upstream.

EricE 5y ago
>The main difference is in the small cases where there is enough community interest to actually take a company's internal patches and do the work of cleaning them up to get them upstream. Exactly. It's also why the argument that open source has an advantage because many eyes can look at the code is also a mostly empty promise, and why things like Heartbeat happened despite everyone knowing the criticality of code like OpenSSL being absolutely solid. If you don't have enough of the right people looking at the right code then you get things like Heartbeat. I'm not pointing this out to argue that Open Source is worthless, but rather to encourage people to not get complacent - Open Source is not a panacea and should still be vetted as you would vet any other part of your solution. >So the result is that, in practice, companies contribute back to GPL-licensed projects for the same reason they contribute back to BSD-licensed projects: because they want to be able to pull in new code from the upstream, and having to rebase a patchqueue every time they want new upstream features is more expensive than engaging with the maintainers to contribute their own code back. You mean people act in favor of their own enlightened self interests? Who could have guess that? Ham fisted attempts to force people to do the right "moral" thing rarely succeed. But we have people who insist "if we just had a better policy!". Sigh. Think of how much more productive we could collectively be if we stopped worrying about how to control other people, but instead structure our approaches to influence their inherent behaviors to get the better outcome naturally? And if they still go their own way shrug and go on? The GPL has evolved into a beast that would make the most aggressive HOA blush - yet the same people who would rightly go after a busybody HOA have no problem cheering misguided efforts like GPL 3 on? It's pretty amazing.

flykespice 5y ago

> BSD gifts companies with an easier path to turning your work into a cloistered and proprietary part of their code Actually, BSD might incentivize "proprietary" companies more than GPL to contribute back to upstream. Even ignoring the gratitude factor for BSD license granting more freedom than GPL, it's just strategic. Companies want to apply their own local patches to the kernel whilst keeping update to upstream changes, it becomes a burden, specially if the infrastructure where the patch touches changes, to ease the burden of maintaining the patches they contribute them to upstream.