Dffcf-123. ,l,km
FreeBSD 10.0 Alpha 1 now available
51–60 of 72 posts
Re: FreeBSD 10.0 Alpha 1 now available
#52Earlier quoted context omitted.
What is the status of ZFS? I have been running Solaris for years only because ZFS is so incredibly good as fileserver for mid sized company and for personal use.
I'm no expert, but ZFS support on FreeBSD seems to be pretty solid (more or less on par with Solaris). FreeNAS seems to be quite popular and it's based on FreeBSD and ZFS. If you have a question about a specific ZFS feature, drop by the FreeBSD forums ( http://forums.freebsd.org ) and ask; the FreeBSD community is generally quite friendly and I'm sure you'll get a good answer to your question. For general information…
Thank you. FreeNAS seems good.
Re: FreeBSD 10.0 Alpha 1 now available
#53I run BSD on all of my desktop boxes, but I have not found any way to run it on a laptop. It just doesn't seem feasible; there are just so many mobile drivers that are missing. Has anyone else had any luck with getting FreeBSD to work on a laptop, or is Linux still the de-facto?
I had FreeBSD running on my old Dell Studio 1737. It took some effort but most of the linux drivers will work with BSD if you edit the source and recompile.
You most definitely can't recompile Linux drivers for FreeBSD. The driver model is very kernel specific, porting drivers is more close to rewriting drivers. Plus there's the GPL thing. Linux is GPL, that's why you'll never see Linux drivers ported to BSDs.
Sys V drivers conforming to the STREAMS model were supposed to be portable between Unix variants, but STREAMS never catched on, neither Linux nor BSDs use STREAMS, and BSDs only have minimal STREAMS support for the SVR4 compatibility layer. Solaris has STREAMS, but has rewritten many drivers not to use the, e.g. the networking stack has been rewritten from being STREAM-based (now it's called Fire Engine).
It's generally easier to port BSD drivers to Solaris, then it is to port BSD drivers to Linux.
Re: FreeBSD 10.0 Alpha 1 now available
#54Can anyone tell me more about the hypervisor ( http://bhyve.org/ )? The design looks extremely similar to KVM, so I don't understand why they didn't just implement the KVM ioctls, on the basis that they would be able to run all the existing userspace (ie. qemu). The problem with implementing a similar-but-different kernel API is that you've either got to persuade qemu to implement your API as well as KVM, or you have…
They don't have to convince anyone, nor rewrite anything. It's a different architecture. Note that not even KVM doesn't technically need Qemu in particular. Qemu is overkill for most usage of KVM, but they used it because it was available. Some people wrote something much smaller that can be used with KVM: https://lkml.org/lkml/2011/3/31/406
Sure, except kvmtool was never accepted upstream and has since been abandoned. To make kvmtool useful would have involved tediously reimplementing large parts of qemu/seabios (qcow2 support, hundreds of emulated devices, firmware). Which is the same thing that FreeBSD will have to do, if they want to run a mix of real world guests any time soon.
Pure programming is great and I've no problem if FreeBSD wants to take years and implement something fantastic.
Re: FreeBSD 10.0 Alpha 1 now available
#55Earlier quoted context omitted.
They don't have to convince anyone, nor rewrite anything. It's a different architecture. Note that not even KVM doesn't technically need Qemu in particular. Qemu is overkill for most usage of KVM, but they used it because it was available. Some people wrote something much smaller that can be used with KVM: https://lkml.org/lkml/2011/3/31/406
Sure, except kvmtool was never accepted upstream and has since been abandoned. To make kvmtool useful would have involved tediously reimplementing large parts of qemu/seabios (qcow2 support, hundreds of emulated devices, firmware). Which is the same thing that FreeBSD will have to do, if they want to run a mix of real world guests any time soon. Pure programming is great and I've no problem if FreeBSD wants to take y…
Emulating real hardware is pointless if your use case is running Linux/FreeBSD in production[1]. It's only important if you want to run historic operating systems or Windows[2]. Effort is more usefully directed into making the hypervisor better rather than implementing legacy cruft. Why should I emulate An A20 gate if my current Linux kernels do just fine without it?
[1] Other people seem to agree with this as they were willing to use Xen before the advent of CPUs which offered hardware assisted virtualization. Xen required a special paravirtualized Linux kernel and people had no problem with this.
[2] In my experience people who want to run Windows use Hyper-V or VMware, not Xen/KVM.
Re: FreeBSD 10.0 Alpha 1 now available
#56Earlier quoted context omitted.
Sure, except kvmtool was never accepted upstream and has since been abandoned. To make kvmtool useful would have involved tediously reimplementing large parts of qemu/seabios (qcow2 support, hundreds of emulated devices, firmware). Which is the same thing that FreeBSD will have to do, if they want to run a mix of real world guests any time soon. Pure programming is great and I've no problem if FreeBSD wants to take y…
Emulating real hardware is pointless if your use case is running Linux/FreeBSD in production[1]. It's only important if you want to run historic operating systems or Windows[2]. Effort is more usefully directed into making the hypervisor better rather than implementing legacy cruft. Why should I emulate An A20 gate if my current Linux kernels do just fine without it? [1] Other people seem to agree with this as they w…
I do agree with this point of view, dislike having to write h/w emulation code for qemu, and have upvoted you; but two points:
People do want to run Windows. More importantly (to me) they want to extend the useful life of ancient Linux distros (usually for software certification reasons) which no longer run on real hardware but could run indefinitely in a VM. For both of those you do need to emulate real hardware.
Second point is if you take it to the logical conclusion, a simple Unix process is the ideal VM: lightweight, secure, well-defined ABI to the OS. From that point of view, jails/cgroups/LXC/seccomp are likely to be even better than your hypothetical ideal-but-doesn't-work-in-the-real-world hypervisor.
Or to put it another way: If you define the goal as "want to run only a mix of recent Linux and FreeBSD guests which happen to have modern but slightly different kernels from the host", then BHyve is certainly the hypervisor for you (except for all the other hypervisors which are battle-tested and have had years of performance improvements, massive community and loads of documentation). If your requirements are even slightly different from that, then you'd be better off with KVM or LXC.
Re: FreeBSD 10.0 Alpha 1 now available
#57Earlier quoted context omitted.
You can currently run FreeBSD instances using cperciva's AMIs, but that's not the same as Amazon supporting FreeBSD in the same way they support Linux. The only "lack of support" which concerns me is the fact that on older EC2 instance types HVM (which FreeBSD uses) is only available by paying for a Windows license. I wouldn't want Amazon to start publishing their own "FreeBSD" images -- those should be provided by t…
That's what I mean -- having to pay for a Windows license you're not using is a strong deterrent to using FreeBSD on AWS; people who might prefer a FreeBSD server end up using Linux instead simply because of the cost difference. You're far more knowledgeable than I (or pretty much anyone else!) about building FreeBSD AMIs, so if you say they should be provided directly by the project, I'm happy to go with that. I wou…
I would just like to see 'FreeBSD' appear as a "mainstream" option when choosing the OS for a new EC2 instance.
That is now fixed in the AWS Marketplace -- although the only AMIs in the marketplace running FreeBSD are my FreeBSD image and Citrix's NetScaler and CloudBridge products.
Will the licensing issue for the smaller AMIs go away once the PVHVM drivers are fully implemented?
No, PVHVM is still a variety of HVM, and on the old instance types that's only available with a "Windows" label attached.
Re: FreeBSD 10.0 Alpha 1 now available
#58Earlier quoted context omitted.
I had FreeBSD running on my old Dell Studio 1737. It took some effort but most of the linux drivers will work with BSD if you edit the source and recompile.
You most definitely can't recompile Linux drivers for FreeBSD. The driver model is very kernel specific, porting drivers is more close to rewriting drivers. Plus there's the GPL thing. Linux is GPL, that's why you'll never see Linux drivers ported to BSDs. Sys V drivers conforming to the STREAMS model were supposed to be portable between Unix variants, but STREAMS never catched on, neither Linux nor BSDs use STREAMS,…
I do find it odd that when BSD people talk about the BSD license, they describe it as pragmatism winning over idealism. However, when they talk about the BSD OS's, suddenly that pragmatism disappear and everything need to be pure permissive licensed.
Is both "camps" just similar fanatic regarding licensing, similar pragmatic, or is it a natural distinct difference when talking about licenses, and when picking software licensed under one of the two types?
Re: FreeBSD 10.0 Alpha 1 now available
#59Earlier quoted context omitted.
You most definitely can't recompile Linux drivers for FreeBSD. The driver model is very kernel specific, porting drivers is more close to rewriting drivers. Plus there's the GPL thing. Linux is GPL, that's why you'll never see Linux drivers ported to BSDs. Sys V drivers conforming to the STREAMS model were supposed to be portable between Unix variants, but STREAMS never catched on, neither Linux nor BSDs use STREAMS,…
I do find it odd that when BSD people talk about the BSD license, they describe it as pragmatism winning over idealism. However, when they talk about the BSD OS's, suddenly that pragmatism disappear and everything need to be pure permissive licensed. Is both "camps" just similar fanatic regarding licensing, similar pragmatic, or is it a natural distinct difference when talking about licenses, and when picking softwar…
> is it a natural distinct difference when talking about licenses, and when picking software licensed under one of the two types?
Of course there is. When I write some software project, of course I want it to be under a specific license, for example BSD. If I chose a BSD license I can't accept GPL patches because that means I can't chose what license I distribute my own software, I have to make it GPL.
As the author, I don't mind if GPL or commercial entities import my software. I am very happy if they do that, I want them to have the freedom to do so. However, I most certainly don't want myself to be forced to change my own license because I import some code. Then, I won't be able to give the freedom of choosing the way they use my software to other people anymore.
Re: FreeBSD 10.0 Alpha 1 now available
#60Earlier quoted context omitted.
I do find it odd that when BSD people talk about the BSD license, they describe it as pragmatism winning over idealism. However, when they talk about the BSD OS's, suddenly that pragmatism disappear and everything need to be pure permissive licensed. Is both "camps" just similar fanatic regarding licensing, similar pragmatic, or is it a natural distinct difference when talking about licenses, and when picking softwar…
> is it a natural distinct difference when talking about licenses, and when picking software licensed under one of the two types? Of course there is. When I write some software project, of course I want it to be under a specific license, for example BSD. If I chose a BSD license I can't accept GPL patches because that means I can't chose what license I distribute my own software, I have to make it GPL. As the author,…
A distribution is not based on patches - its based on picking software packages which to bundled together into a working operative system.
But okay, lets go with the distributions desire to chose what license to use. Who cares about the license? The whole point of pragmatism winning over idealism is to achieve a set of practical effects, regardless lofty concept such as "freedom of choosing license".
A distribution is most effective when it can use the best software as much as it can. This mean that a pragmatic distribution should use any software, be that proprietary, GPL, permissive, anything, so long it is superior. A pragmatic approach to license issues would be to have built in tools to slim down the distribution to reach specific practical effects depending on the need of each individual users.
Surely, giving people working graphic drivers is more pragmatic than giving people nothing and say "the software that give your practical use from your hardware is under the wrong license".