
FreeBSD 10.0 Alpha 1 now available - daw___
http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044522.html
======
lcampbell
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!

\--

[1]
[https://wiki.freebsd.org/WhatsNew/FreeBSD10](https://wiki.freebsd.org/WhatsNew/FreeBSD10)

[2] [http://7he.at/freebsd/vps/](http://7he.at/freebsd/vps/)

[3]
[https://wiki.freebsd.org/action/show/bhyve?action=show&redir...](https://wiki.freebsd.org/action/show/bhyve?action=show&redirect=BHyVe)

~~~
gonzo
it's likely to make the cut, given that it's pretty damned stable.

virio will be huge.

~~~
rwmj
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).

------
lifeisstillgood
quick summary for the impatient:

\- 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

~~~
profquail
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).

[1]: [http://lists.freebsd.org/pipermail/freebsd-
xen/2013-June/001...](http://lists.freebsd.org/pipermail/freebsd-
xen/2013-June/001618.html)

[2]:
[http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM](http://wiki.xen.org/wiki/Testing_FreeBSD_PVHVM)

[3]:
[http://forums.freebsd.org/showthread.php?t=38019](http://forums.freebsd.org/showthread.php?t=38019)

[4]: [http://www.daemonology.net/freebsd-on-
ec2/](http://www.daemonology.net/freebsd-on-ec2/)

~~~
gonzo
[http://aws.typepad.com/aws/2012/11/aws-marketplace-
additiona...](http://aws.typepad.com/aws/2012/11/aws-marketplace-additional-
operating-system-support.html)

edit: we're about to launch pfSense on EC2, too.

~~~
cperciva
Can you send me an email about this? I like to keep track of how FreeBSD/EC2
is being used and I might be able to help you.

------
kunai
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?

~~~
eulerphi
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.

~~~
4ad
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.

~~~
belorn
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?

~~~
4ad
> 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.

~~~
belorn
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".

~~~
4ad
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.

~~~
belorn
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.

~~~
4ad
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).

~~~
belorn
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.

~~~
4ad
> 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.

~~~
belorn
> 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.

See: [http://stackoverflow.com/questions/4854519/gpl-component-
in-...](http://stackoverflow.com/questions/4854519/gpl-component-in-bsd-
project)

Or this almost 2 year old answer on HN:
[https://news.ycombinator.com/item?id=4359524](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:

    
    
      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. 
    

-> [http://info.iet.unipi.it/~luigi/freebsd/linux_bsd_kld.html](http://info.iet.unipi.it/~luigi/freebsd/linux_bsd_kld.html)

~~~
GalacticDomin8r
> That is factually wrong.

That 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.

~~~
belorn
> 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.

~~~
GalacticDomin8r
Do these words look familar?

> 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?

~~~
belorn
> 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.

> Where was that?

[https://news.ycombinator.com/item?id=6426384](https://news.ycombinator.com/item?id=6426384)

~~~
GalacticDomin8r
> Perhaps you should read your own words before replying.

Perhaps you should read your own words before replying.

>> Where was that? >
[https://news.ycombinator.com/item?id=6426384](https://news.ycombinator.com/item?id=6426384)

No, someone else may have said it, I didn't. Please quit misattributing words
to me.

------
rwmj
Can anyone tell me more about the hypervisor
([http://bhyve.org/](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).

~~~
4ad
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](https://lkml.org/lkml/2011/3/31/406)

~~~
rwmj
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.

~~~
4ad
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.

~~~
rwmj
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.

------
ubikation
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?

~~~
kev009
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...](http://www.slideshare.net/syuu1228/implements-bios-
emulation-support-for-b-hy-ve-a-bsd-hypervisor). 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.

------
pjenvey
What's new:
[https://wiki.freebsd.org/WhatsNew/FreeBSD10](https://wiki.freebsd.org/WhatsNew/FreeBSD10)

------
synchronise
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.

------
a--b
I've had a long standing question about FreeBSD and ports/portsnap: does/how
does FreeBSD prevent against bad mirrors or MITM attacks?

~~~
gaadd33
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?

~~~
adestefan
Most Linux package managers use GPG signed packages.

~~~
profquail
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.

~~~
adestefan
Very few Linux distributions have the equivalent of FreeBSD's ports. I know of
the Arch Linux AUR and they also use checksums in their PKGBUILD files.

------
erichurkman
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.

~~~
profquail
The `netmap` stuff (high-performance networking stack) is really neat. The
author's site has a lot more information about it if you're interested:

[http://info.iet.unipi.it/~luigi/netmap/](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.

~~~
wmf
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.

------
telephonetemp
Is there information as to whether pkgng will be available in time for the
10.0 release?

~~~
profquail
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:

[https://wiki.freebsd.org/pkgng/CharterAndRoadMap](https://wiki.freebsd.org/pkgng/CharterAndRoadMap)

------
freeman478
Dffcf-123. ,l,km

