The What's New for FreeBSD 10 wiki page[1] linked in the reply has more details (though it doesn't necessarily indicate what will make the cut). The interesting bits to me are the merging of VPS support[2] which, last I read was a patchset against the 7 or 8 kernel. The seamless migration of virtualized envs seemed like a pipe dream at the time, I can't wait to play around with it (if it makes the cut).
Not to mention virtio support and bhyve[3] (in addition to the old jail subsystem). If everything makes it in, there will be so many different options for service isolation!
Virtio is excellent news, and I'm glad to see they've implemented virtio-scsi which is just in every way much better than the old virtio-blk (although they've implemented that too).
bhyve seems very interesting - is there any mention of IO and CPU throttling ? I want to be able to at least have rudimentary control of how many CPU cycles a VM is allowed to use, when competing with other VMs for the same CPU cycles and resources.
So how does bhyve compare to kvm? I've seen FreeBSD people saying it's a 'legacy free' virtualization system but I don't really know what that means or entails.
Can it do live migrations and failovers like xen/kvm?
What can it do that kvm/xen can't? What about vice versa?
It's legacy free in the sense that it doesn't do paravirt like Xen and requires hardware assistance like KVM. Maybe also that it doesn't use QEMU which has some pros and cons: http://www.slideshare.net/syuu1228/implements-bios-emulation.... Ultimately, it will let people like NetApp use it on their filers without any GPL complications though.
In all other respects, it's still in its infancy and I wouldn't expect KVM parity for common use cases until the next release. I'm more excited about the VIMAGE stuff in 10.
Personally I can't wait to use 10 when it gets released.
But it's a pity that it won't see Gnome 3.10 due to its dependence on logind, and then logind's new dependency on systemd as of 205.
AFAIK ports checks the checksum of the file when it downloads it against the checksums the ports maintainer submitted.
For the ISO mirrors, I don't think there's anything automatic, you have to manually run sha256 on the file and compare checksums. Do Linux distributions have another way?
yes but a one time md5 of an iso is far less strenuous than manually checking the provenance of 200 tarballs to build say X. there is a new package management system similar to apt-get but it's far rarer to see it used than ports
I really like ports - as much for the knowledge that I have all the right header files.
When do you have to check the provenance of 200 tarballs to install X? If you install from an ISO, you can install the ports from there too and you have checksums which are automatically checked, right? So if you do cd /usr/ports/x11-wm/xfce4; make install it will automatically check all of the checksums right?
err, maybe. I don't think I have ever installed x from pkgs on cd. I always download thru ports - the 200 tarballs was what ports does for me (downloads and verifies md5) so if I did not use ports and I did build from source I would manually download and verify. I don't think anyone would ever do that admittedly.
In FreeBSD (and the other BSDs), packages and ports are two separate things. Packages are binary distributions; a port is just a set of patches (if necessary) and a special makefile telling the build system where to download the sources for the software you want to build and any special instructions necessary to build/install it.
It makes sense to sign packages, but not ports. Ports do contain checksum files though, to make sure the source tarball/zip you download hasn't been changed -- this is what 'gaadd33' was referring to.
The portsnap buildbox checks out the ports tree over an encrypted and authenticated pipe to the central SVN server. It then packages up the ports tree and signs the result before uploading those bits to the portsnap mirrors.
The portsnap client has hash of the signing public key (in /etc/portsnap.conf, where it was placed during the install process) and uses that to check the validity of the bits it downloads from a portsnap mirror.
It sounds like some amazing performance boosts around networking. I wonder how much of that will carry over to all of the network-type appliances built on FreeBSD? I know Juno's OS runs a pretty ancient version of FreeBSD (6 or 7 IIRC), but am not sure about any other commercial uses.
I'm curious to see what kind of performance is possible with FreeBSD 10 (using `netmap`) and the new I/O manager which will be included in the upcoming GHC 7.8 release. The combination seems like it would be epic in terms of web server performance, and it might be a nice choice for web hosting companies / CDNs who have a vested interest in reducing latency as much as possible.
First somebody needs to create a TCP stack for Netmap; right now it only deals in Ethernet packets. Netmap has the potential for very high performance; we're capturing 50 Gbps and hoping to hit 140 Gbps per server soon.
Hmm, it might make some difference on some of the Juniper lines (is the SRX line software-based?) but any of the high-end Juniper products are only using JunOS for the control plane. Only control traffic and certain exception cases (e.g. ICMP) ever hit the BSD/JunOS network stack; the rest is all handled in hardware.
- introduce VPS (more virtualised approach to jails)
- introduce bhyve (native hypervisor on common standards)
- replace BIND
- Can be run on raspberry pi
- major speed ups in SMP, and networking
FreeBSD Is taking a fairly big leap forward in its sweet spot of the workhorse of the data farm. BSD has always had great jails virtualisation support (it's what LXC or docker is following) but now that's being expanded and complemented with the run-another-OS-on-my-host-OS of "virtio" style VMs
Raspberry pi of course is what the world has been waiting for - never mind all the rest :-)
FreeBSD 10 is also going to have much-improved support for Xen [1][2] and newly-added support for Hyper-V [3]. I'd love to see AWS and Azure support first-class FreeBSD instances. (You can currently run FreeBSD instances using cperciva's AMIs [4], but that's not the same as Amazon supporting FreeBSD in the same way they support Linux).
agreed with AWS and freebsd. although there is hardly the demand - each year I have a debate whether to forego BSD entirely (especially on the desktop) but its just that too good to lose.
it looks like I'm going to get saltstack working with VpS and keep with Rackspace :-)
It's a chicken/egg problem -- Amazon won't be motivated to implement additional support for FreeBSD without more people asking for it, but the additional visibility FreeBSD would gain from better support on AWS (and/or Azure) would definitely increase the number of people using it. It seems like FreeBSD has seen an upswing in interest over the past couple of years, and if interest keeps growing I think it'd eventually hit some threshold where Amazon is willing to implement better support for FreeBSD and then put some marketing behind it.
On FreeBSD + saltstack: I saw an interesting article a few weeks back (on the saltstack website, no less) about them implementing better support for FreeBSD, specifically w.r.t. jails:
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 the project.
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 would just like to see 'FreeBSD' appear as a "mainstream" option when choosing the OS for a new EC2 instance. (See gonzo's link -- the dialog shown in the picture has 15 Linux distributions available; it'd be nice for FreeBSD to be on that menu.)
Will the licensing issue for the smaller AMIs go away once the PVHVM drivers are fully implemented? I don't know a whole lot about Xen, so I'm curious to know what needs to be implemented to fix that problem.
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.
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 about FreeBSD + ZFS, check out these links:
I'm not the one to ask but, on the FreeBSD forum, it's all that's talked about. That is, everyone is using it and there are a multitude of questions from people asking how to use it. From what I gather, it is every bit as good as Solaris or at least approaches it. Again, I'm a FreeBSD user but not the person who would know.
I 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.
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?
> 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.
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".
BSDs are not distributions. They are complete operating systems. They don't pick software packages, they develop almost all necessary software themselves (notable exceptions include gcc which the BSDs are trying to get rid of).
BSDs are pragmatic in that they don't restrict their users in their usage of the provided code. That's how Cisco's IOS and Juniper's Junos can exist.
The BSD ports contain many GPL software and non-GPL software (including closed source graphics drivers) that you can install on your own. They are not part of the base operating system.
Some believe that permissive licenses are good because it do not restrict their users. Some believe that copyleft licenses are good because it do not restrict users of derivate version. Both are views, rather than practical actions. They are just thoughts about the promised land that licenses might give.
The parent post talked about porting hardware drivers from Linux to BSD kernel. The BSD project decide against it, citing the license as reasons. As a result, BSD users goes without because the drivers are not of the right license.
Pragmatism: Based on practical uses and successes rather than in terms of believing.
Idealism: Mentally constructed ideas on how things ought to be best. Its priorities what it believes over practical gain.
Deciding against practical gain because of an mentally constructed idea is Idealism over Pragmatism.
Porting a GPL driver to BSD helps only a few people (those who have the particular hardware) to the detriment of every contributor and every consumer of the code (like Cisco, Juniper and Apple).
How is that to the detriment of every contributor? They can simply opt out of using that driver. Are you implying that Cisco, Juniper and Apple don't have the expertise to exclude drivers that they don't want?
You are trying to decide for those "few" people that they are better off without working drivers. Maybe some people do like having working graphic cards or working sound. It takes a quite fundamental approach to ignore practical use over idealism present in a license text.
Not that this discussion matter much... FreeBSD has a linux compatibility layer, which mean they can often run said GPL drivers through its port system. Its only with the base system that useful drivers get thrown out with the bath water in favor of license purity.
> How is that to the detriment of every contributor? They can simply opt out of using that driver.
No, it doesn't work like that. You can't make driver X in the kernel GPL without making the whole kernel code GPL.
> You are trying to decide for those "few" people that they are better off without working drivers. Maybe some people do like having working graphic cards or working sound.
Aside from the fact that sound works better in FreeBSD compared to Linux (because of OSS4) and that graphics is at least on par with Linux (or better; the proprietary FreeBSD driver continues to work without recompiling the kernel shim every time the kernel is updated), you are completely missing the point. Some guy who complains on the Internet that FreeBSD doesn't work on his laptop is of no value to FreeBSD. Valuable users are those who contribute code, those who run large installations, and those who use the code to build their products. These always take priority and every decision happens with them in mind, not random dudes on the Internet. You're complaining about sound and graphics? I'm having a hard time believing this is a serious discussion, why not complain about the lack of sound and graphics on a PIC32 microcontroller.
> FreeBSD has a linux compatibility layer, which mean they can often run said GPL drivers through its port system.
No, this is impossible. Linuxemu is a compatibility layer for Linux user-mode binaries. It emulates the Linux system call interface. It cannot be used with Linux drivers. As mentioned above, the driver model is very different between different operating systems.
> You can't make driver X in the kernel GPL without making the whole kernel code GPL.
That is factually wrong. You are perfectly fine in keeping the rest of the kernel under BSD. GPL only prevents added restrictions from being added to the GPL code itself, or the combined work. If users downstream remove said code, then it would not be a combined work anymore.
> Linuxemu is a compatibility layer for Linux user-mode binaries. It emulates the Linux system call interface. It cannot be used with Linux drivers.
Quoting Luigi Rizzo:
I decided to start working on an emulation layer that would let
us recompile the linux source code on FreeBSD, and provide a
sufficiently complete emulation of the kernel APIs so that
device drivers (or at least certain classes) could be used
without modifications to their source code.
Did you even bother reading the sources you cited or ever read the GPL? The first couple links side with the OP and the third doesn't address the OP's point.
> Authors of individual files are clearly free to release their own work under BSD even inside such a GPL-licensed compilation, and if someone takes out all GPL code, the result can be distributed under BSD license.
> BSD doesn't need to "relicense" anything as the license to the existing code already permits combining with the GPL.
I don't see how it can be made any more clear. If you remove the GPL code, it no longer need to be under GPL. Did you bother to read the sources, and do you have any sources to support your clearly false claims?
The third link was about the linux emulation laying being used to including linux drivers into freebsd through the port system. You said it was impossible, yet they did it. The impossible happened, and is/was used for USB support particularly.
> GPL only prevents added restrictions from being added to the GPL code itself, or the combined work. If users downstream remove said code, then it would not be a combined work anymore.
Perhaps you should read your own work before replying.
> Perhaps you should read your own work before replying.
Perhaps you should read your own words before replying.
>> You said it was impossible, yet they did it.
> O'rly?
>>>> No, this is impossible. Linuxemu is a compatibility layer for Linux user-mode binaries. It emulates the Linux system call interface. It cannot be used with Linux drivers.
>>> emulation layer ... provide a sufficiently complete emulation of the kernel APIs so that device drivers could be used.
Don't bother. Look at his comment history; he seems to be a complete anti-BSD zealot and spreads FUD about the BSD projects and BSD licenses.
As for linux compatibility, the provided link has nothing, nothing whatsoever with linuxemu, the Linux API compatibility layer provided by the FreeBSD base system. I won't bother anymore, as by reading his post history it's obvious he mixes BSD technology and terminology because he is completely unfamiliar with the concepts he speaks about.
I have used BSD on all my laptops for the past eight ? years. wifi is my biggest bugbear but I fear I generally ignore anything that is not germane to the basics.
Yes, I'd be interested to learn more from experienced laptop users as well. Especially, how does BSD do in some areas that Linux still struggles sometimes, such as e.g.:
- suspend/resume
- power consumption/battery life
- multiple monitor support
- wifi drivers
- etc.
Does anyone have some experience with these (and other) points and would like to comment?
I ran FreeBSD on my Acer Aspire One ZG5 netbook for nearly a year before I got a new laptop. The one thing that wasn't working in 9.1 was suspend/resume/hibernate.
Hopefully the suspend/resume issue will be rectified in 10.0.
I haven't tried FreeBSD on my new laptop yet, as it is equipped with the BCM 4313 Wireless adaptor, and I'm not ready to fool with that just yet...
I used to run FreeBSD on my Toshiba Satellite C660-180 and encountered no issues. Everything seemed to work out of the box and performance was on par with version 3.2 of the Linux kernel.
I keep meaning to switch back to FreeBSD, actually. This alpha may prompt me to give it a shot.
Can 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 to rewrite the whole of qemu (a massive job).
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.
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.
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.
AFAIK, pkgng is the default package manager in both FreeBSD 9.2 (due any day now) and 10.0. The table at the bottom of this page says so anyway, and it was updated just a few months back:
71 comments
[ 2.7 ms ] story [ 130 ms ] threadNot to mention virtio support and bhyve[3] (in addition to the old jail subsystem). If everything makes it in, there will be so many different options for service isolation!
--
[1] https://wiki.freebsd.org/WhatsNew/FreeBSD10
[2] http://7he.at/freebsd/vps/
[3] https://wiki.freebsd.org/action/show/bhyve?action=show&redir...
virio will be huge.
Can it do live migrations and failovers like xen/kvm?
What can it do that kvm/xen can't? What about vice versa?
In all other respects, it's still in its infancy and I wouldn't expect KVM parity for common use cases until the next release. I'm more excited about the VIMAGE stuff in 10.
For the ISO mirrors, I don't think there's anything automatic, you have to manually run sha256 on the file and compare checksums. Do Linux distributions have another way?
I really like ports - as much for the knowledge that I have all the right header files.
It makes sense to sign packages, but not ports. Ports do contain checksum files though, to make sure the source tarball/zip you download hasn't been changed -- this is what 'gaadd33' was referring to.
The portsnap client has hash of the signing public key (in /etc/portsnap.conf, where it was placed during the install process) and uses that to check the validity of the bits it downloads from a portsnap mirror.
http://info.iet.unipi.it/~luigi/netmap/
I'm curious to see what kind of performance is possible with FreeBSD 10 (using `netmap`) and the new I/O manager which will be included in the upcoming GHC 7.8 release. The combination seems like it would be epic in terms of web server performance, and it might be a nice choice for web hosting companies / CDNs who have a vested interest in reducing latency as much as possible.
- drop GCC for CLANG.
- introduce VPS (more virtualised approach to jails)
- introduce bhyve (native hypervisor on common standards)
- replace BIND
- Can be run on raspberry pi
- major speed ups in SMP, and networking
FreeBSD Is taking a fairly big leap forward in its sweet spot of the workhorse of the data farm. BSD has always had great jails virtualisation support (it's what LXC or docker is following) but now that's being expanded and complemented with the run-another-OS-on-my-host-OS of "virtio" style VMs
Raspberry pi of course is what the world has been waiting for - never mind all the rest :-)
edit: tidy ups
[1]: http://lists.freebsd.org/pipermail/freebsd-xen/2013-June/001...
[2]: http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM
[3]: http://forums.freebsd.org/showthread.php?t=38019
[4]: http://www.daemonology.net/freebsd-on-ec2/
it looks like I'm going to get saltstack working with VpS and keep with Rackspace :-)
It's a chicken/egg problem -- Amazon won't be motivated to implement additional support for FreeBSD without more people asking for it, but the additional visibility FreeBSD would gain from better support on AWS (and/or Azure) would definitely increase the number of people using it. It seems like FreeBSD has seen an upswing in interest over the past couple of years, and if interest keeps growing I think it'd eventually hit some threshold where Amazon is willing to implement better support for FreeBSD and then put some marketing behind it.
On FreeBSD + saltstack: I saw an interesting article a few weeks back (on the saltstack website, no less) about them implementing better support for FreeBSD, specifically w.r.t. jails:
http://intothesaltmine.org/blog/html/2013/08/30/bootstrappin...
edit: we're about to launch pfSense on EC2, too.
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 the project.
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 would just like to see 'FreeBSD' appear as a "mainstream" option when choosing the OS for a new EC2 instance. (See gonzo's link -- the dialog shown in the picture has 15 Linux distributions available; it'd be nice for FreeBSD to be on that menu.)
Will the licensing issue for the smaller AMIs go away once the PVHVM drivers are fully implemented? I don't know a whole lot about Xen, so I'm curious to know what needs to be implemented to fix that problem.
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.
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 about FreeBSD + ZFS, check out these links:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/fi...
https://wiki.freebsd.org/ZFS
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.
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?
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.
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".
BSDs are pragmatic in that they don't restrict their users in their usage of the provided code. That's how Cisco's IOS and Juniper's Junos can exist.
The BSD ports contain many GPL software and non-GPL software (including closed source graphics drivers) that you can install on your own. They are not part of the base operating system.
The parent post talked about porting hardware drivers from Linux to BSD kernel. The BSD project decide against it, citing the license as reasons. As a result, BSD users goes without because the drivers are not of the right license.
Pragmatism: Based on practical uses and successes rather than in terms of believing.
Idealism: Mentally constructed ideas on how things ought to be best. Its priorities what it believes over practical gain.
Deciding against practical gain because of an mentally constructed idea is Idealism over Pragmatism.
You are trying to decide for those "few" people that they are better off without working drivers. Maybe some people do like having working graphic cards or working sound. It takes a quite fundamental approach to ignore practical use over idealism present in a license text.
Not that this discussion matter much... FreeBSD has a linux compatibility layer, which mean they can often run said GPL drivers through its port system. Its only with the base system that useful drivers get thrown out with the bath water in favor of license purity.
No, it doesn't work like that. You can't make driver X in the kernel GPL without making the whole kernel code GPL.
> You are trying to decide for those "few" people that they are better off without working drivers. Maybe some people do like having working graphic cards or working sound.
Aside from the fact that sound works better in FreeBSD compared to Linux (because of OSS4) and that graphics is at least on par with Linux (or better; the proprietary FreeBSD driver continues to work without recompiling the kernel shim every time the kernel is updated), you are completely missing the point. Some guy who complains on the Internet that FreeBSD doesn't work on his laptop is of no value to FreeBSD. Valuable users are those who contribute code, those who run large installations, and those who use the code to build their products. These always take priority and every decision happens with them in mind, not random dudes on the Internet. You're complaining about sound and graphics? I'm having a hard time believing this is a serious discussion, why not complain about the lack of sound and graphics on a PIC32 microcontroller.
> FreeBSD has a linux compatibility layer, which mean they can often run said GPL drivers through its port system.
No, this is impossible. Linuxemu is a compatibility layer for Linux user-mode binaries. It emulates the Linux system call interface. It cannot be used with Linux drivers. As mentioned above, the driver model is very different between different operating systems.
That is factually wrong. You are perfectly fine in keeping the rest of the kernel under BSD. GPL only prevents added restrictions from being added to the GPL code itself, or the combined work. If users downstream remove said code, then it would not be a combined work anymore.
See: http://stackoverflow.com/questions/4854519/gpl-component-in-...
Or this almost 2 year old answer on HN: https://news.ycombinator.com/item?id=4359524
> Linuxemu is a compatibility layer for Linux user-mode binaries. It emulates the Linux system call interface. It cannot be used with Linux drivers.
Quoting Luigi Rizzo:
-> http://info.iet.unipi.it/~luigi/freebsd/linux_bsd_kld.htmlThat answer is factually wrong.
Did you even bother reading the sources you cited or ever read the GPL? The first couple links side with the OP and the third doesn't address the OP's point.
> BSD doesn't need to "relicense" anything as the license to the existing code already permits combining with the GPL.
I don't see how it can be made any more clear. If you remove the GPL code, it no longer need to be under GPL. Did you bother to read the sources, and do you have any sources to support your clearly false claims?
The third link was about the linux emulation laying being used to including linux drivers into freebsd through the port system. You said it was impossible, yet they did it. The impossible happened, and is/was used for USB support particularly.
> GPL only prevents added restrictions from being added to the GPL code itself, or the combined work. If users downstream remove said code, then it would not be a combined work anymore.
Perhaps you should read your own work before replying.
> You said it was impossible, yet they did it.
O'rly? Where was that?
Perhaps you should read your own words before replying.
>> You said it was impossible, yet they did it.
> O'rly?
>>>> No, this is impossible. Linuxemu is a compatibility layer for Linux user-mode binaries. It emulates the Linux system call interface. It cannot be used with Linux drivers.
>>> emulation layer ... provide a sufficiently complete emulation of the kernel APIs so that device drivers could be used.
> Where was that?
https://news.ycombinator.com/item?id=6426384
Perhaps you should read your own words before replying.
>> Where was that? > https://news.ycombinator.com/item?id=6426384
No, someone else may have said it, I didn't. Please quit misattributing words to me.
As for linux compatibility, the provided link has nothing, nothing whatsoever with linuxemu, the Linux API compatibility layer provided by the FreeBSD base system. I won't bother anymore, as by reading his post history it's obvious he mixes BSD technology and terminology because he is completely unfamiliar with the concepts he speaks about.
Intel Graphics work great (wiki.freebsd.org/Intel_GPU) I have great wireless support for my Intel Centrino 6235
Ports also provides all the applications I could ever need (Emacs, Vim, FireFox, Chromium, SBCL, Chicken, MPD etc..)
I really love running FreeBSD on my laptop, I am a big tinkerer and this is the first time I have gotten a setup that feels right
seriously want a write up?
- suspend/resume - power consumption/battery life - multiple monitor support - wifi drivers - etc.
Does anyone have some experience with these (and other) points and would like to comment?
Hopefully the suspend/resume issue will be rectified in 10.0.
I haven't tried FreeBSD on my new laptop yet, as it is equipped with the BCM 4313 Wireless adaptor, and I'm not ready to fool with that just yet...
I keep meaning to switch back to FreeBSD, actually. This alpha may prompt me to give it a shot.
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 to rewrite the whole of qemu (a massive job).
Pure programming is great and I've no problem if FreeBSD wants to take years and implement something fantastic.
[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.
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.
https://wiki.freebsd.org/pkgng/CharterAndRoadMap