GCC is still in the base FreeBSD source tree, and is still used for CPU architectures where Clang support is not sufficiently mature. In addition, the article claims that GCC will remain "for a time" in the ports tree. GCC isn't going to be removed from the ports tree.
There's a spurious reference to "atomic close-on-exec" here.
PF itself was ported from OpenBSD, while the SMP improvements were developed in FreeBSD.
Netmap is a very high performance _Layer 2_ Ethernet packet interface; the reference to "65536 routing tables" is not applicable.
There are also a few items on here which are either works in progress or brainstorming ideas, and are not likely to be available in FreeBSD 10.0 (but may arrive in a later 10 point release): Variable symlinks, full UEFI, PCI hot-plug, Thunderbolt.
Variable symlinks stood out as a bit of a surprise on that list. Everything else is understandable as either an improvement in the implementation of an established feature, or an improvement of a feature in FreeBSD's core areas of excellence (eg networking and storage), or a sop to the fashion for virtualisation. But variable symlinks seem, to my ignorant eyes, like a new feature that is not aimed at any particular strategic goal, just some cool thing.
What is the rationale behind adding variable symlinks? Are they necessary to support some other feature? Are they being adopted for parity with some other form of UNIX? Is there a considered opinion that they will be found widely useful?
I know that's one of the features that DragonflyBSD has had for a while. I've never found much documentation surrounding the issue, but it's always been referred to as something that helps administrators set up different environments for different users. When users need to share most of an environment but with a few exceptions, you can just use a variant symlink for the differences, instead of setting up a jail and sharing everything else some other way.
Let's assume you use multiple routing tables (FIBs) wouldn't be nice to have the resolve.conf be a variable symlink dispatching on the processes default FIB instead of having to put processes into chroot environments (or jails)?
We recently switched from a Debian and Cloud hybrid to FreeBSD. Result: We have recent, stable software (Ports rock!), we are overall more stable than we were on the cloud, we have no more need to work around limitations of clouds and we have more resources while only paying a fraction, compared to our cloud service. Because of this we can have way more systems, which means we can use that for HA and are always set up for a sudden increase of users. With FreeBSD's jails we have a perfect cloud-like separation of services.
I used to be a huge fan of cloud computing, but what I really dislike these days is that while it makes it easier and way cheaper for companies it actually brings close to zero benefits to users, even being more expensive and connected with more limitations. A lot of the time people seem to use cloud hosting, because everyone else does so and because it is a hype right now.
It partly explains it, because for some it might be a reason to go for clouds in first place. I agree, it's not always the case.
However as explained I think there are many wrong expectations coming from clouds:
- Isolation: Like already mentioned. You can use jails and nowadays LXC
- Up to date software: Either managed or with special/official images (again the isolation comes up her). This is a reason for FreeBSD. Their ports system and base system allow for both stability and up to date software. Big plus for startups, because they usually depend more on this than others.
- Uptime: I don't know why this is so big. If you are designing (mostly) stateless systems, like for the cloud you usually have the same benefits off the cloud. You have to pay for HA (many instances) on the cloud. It doesn't make it magically more available. However, if you go off the cloud, even reserved Amazon instances you can easily build extremely high availability cause it will cost less for you. One big thing when cloud computing game up was how great it is that resources can be used more efficiently and how it is cheaper for that reason. However, because of all the hype (I guess) it is only cheaper for cloud hosts.
- Scale out: Again, this is a question of cost: Do you start out with two or three instances in the cloud or for the same money just get 5-10 real systems (no joke, look how cheap professional grade hosting became!) so you don't need to bother in first place?
So you end up with less resources and higher costs and potentially cannot (or have a harder time to) run certain services that simply are not optimized for the cloud. Again, if you design your software to run in the cloud you usually have software that on real hardware is close to zero maintenance (well, at least less than what you have to do for clouds anyway).
I am sure there are good reasons for running FreeBSD on the cloud instead of just buying your own machines and connect them (over multiple data centers if you worry a lot). And we actually also use the cloud for backups.
However I really think that often the term cloud is used as just another buzzword and the benefits are mostly imagined, caused by a huge hype, not always, but way too often.
Don't get me wrong, I am not against cloud computing at all. I just came across way to many people/startups paying for expensive cloud infrastructure seemingly not having any reason for it, other than it being hyped. When I ask why they do it then they either don't know or have really wrong expectations.
I loved FreeBSD all through the late 90s / early 2000s in high school and college. I was working for a small ISP that ran 100% FreeBSD and cut my teeth on *nix in general on the platform. My first foray into Linux (Debian) felt sloppy and discombobulated comparatively. Why? FreeBSD is an entire OS, not a menagerie of tools wrapped around a common kernel. FreeBSD always felt much more polished, complete and predictable. Unfortunately our team made the choice to migrate to Debian for ease of upgrades and security patches (no more building world). Back in the day the limited resources from a processing perspective made those upgrades much longer than an apt-get upgrade.
I love Linux (Arch / Debian), but I still have a soft spot for FreeBSD. I have flashbacks to the network install via a floppy that remind me of the simpler time of the Internet. I need to re-engage with 10. Lots of great platforms I use are still based on it - FreeNAS and PFSense.
If you've never tried it, I encourage you to learn the system.
After working Solaris and AIX for years, I still prefer BSD's userland to Linux's, but Linux's overwhelming HW support eventually won me over. Would anyone else here be interested in a distro with a Linux kernel with FreeBSD's userland? I've experimented with Starch Linux and MirOS, but both are pre-alpha.
What's better about the FreeBSD userland? Are you talking about the shell tools like coreutils/diffutils/etc., or more about daemons like DNS/mail/etc.?
I am actually thinking of doing the opposite: using GNU user land tools (coreutils etc.) with the FreeBSD kernel. I know there are some projects already in this direction -- Debian/BSD, Arch/BSD, and I think Gentoo has some relation to BSD.
Reason: I want some BSD kernel features but don't want to waste time porting shell scripts and so forth.
Most of your list is just the fact that FreeBSD has a giant ifconfig binary instead of separate tools for different features. That's mostly a taste issue. Certainly dumping everything in the same tool is no less "confusing". I just googled the FreeBSD man page for ifconfig -- yikes!
The last bit is unfair. Yes, Linux distros have recently diverged on network device naming. But that's for a good reason: the old scheme wasn't robust against probe order, the new systemd one is, and FreeBSD's isn't either. The systemd naming (while ugly) is better, period. That's a feature for Linux, not a confusing problem with its userland.
> the old scheme wasn't robust against probe order
> and FreeBSD's isn't either
Very untrue. FreeBSD does serial enumeration which results in static devices each time. There is no equivalent tool in FreeBSD to udev or systemd because it isn't needed(although devd does a certain subset of some of their functionality). About the only place out of order probing can occur is with external disk expander where FBSD isn't doing the actual probing. In this case, labeling disks or using the cam wire down method. man 4 cam
I bet you it doesn't. The BSD name a driver name and a number, and that's not enough state. If you swap two identical cards between PCIe slots, does it still work? If you pull em1 and add a new card in its place does it come up as em1 (incorrect) or em2? If you have a fixed external network with its own routing rules on a USB ethernet adapter, does it work correctly if you happen to boot with another such device connected?
I admit I'm chuckling a little about the idea of udev not being "needed". :)
If you pull em1 and add a new card in its place does it come up as em1 (incorrect) or em2?
Am I misreading, or do you mean to say that if you replace a failed part, the ‘correct’ thing is for the replacement to come up with a different name so that the box stays out of production until someone can manually reconfigure it?
I have to use linux for work, but he's right, keeping everything in ifconfig is much more close to the old school "unix" way than "lets play 20 commands" that seems to be present in most linux mindsets.
> Most of your list is just the fact that FreeBSD has a giant ifconfig binary instead of separate tools for different features. That's mostly a taste issue.
No, its not that.
It clearly shows how fragmented Linux ecosystem is..
On Freebsd, on the other side, if a new kernel/OS feature
is created, the enginner/designer of that feature can count on, create (or modify) existing tools in the userland, cause he knows the userland will ship together
with the modified version of the kernel(or dinamic module)
It gives the whole system, a consistency; not easilly found anywhere else,
much less in Linux.. if you start to use Freebsd for some time,
you will just note this..
It gives you a better, and consistent experience,
and i think is this what Unix should look like..
The need for binary updates is certainly understandable, and was a reasonably common complaint. Binary updates have now largely become a "solved problem" on FreeBSD, through freebsd-update (ca. 2007, for the base system) and pkgng (ca. today, for third party software).
I dont think theyre a solved problem yet. Strangely enough the ports system appears to be too flexible. Which one should I be using in 2013 to install packages - pkg_add, pkgng, portmaster, portupgrade, running make install from within the ports source tree? Could someone who knows more about FreeBSD than I do comment on whats state of the art in terms of installing / upgrading packages?
ports - `cd /usr/ports/mail/postfix && make install` compiles postfix from source, as an example. It allows you tremendous and easy control over compile time options. No hunting down just the right package for the features you need. No waiting for some long lost maintainer to update their package. Everything is compiled against the libraries you have installed.
pkg_add - Installs a binary package that someone else compiled directly from the port. Fast and easy. These may lag behind a little bit behind bleeding edge, and you don't get to choose compile-time options. You can (mostly) mix and match software installed from pkg_add and ports.
pkgng - is the new binary package management system. It is pretty great, but still teething a bit. PC-BSD is offering the most up to date pkgng style package repository was twice-monthly updates. You have to set your system up as old style package (still default) or the new pgkng, and you can't mix and match different package types.
portmaster - is a software upgrade tool, and I think the most popular at this time. It just uses the ports tree (or optionally packages) to do the magic.
portupgrade - the former favorite, works much like portmaster to upgrade software (and perform other tricks) on top of the ports/packages system.
poudriere - Another ports upgrade tool. It has many fans. Harder for Americans to spell.
At this time, I would recommend using ports to install things, and portmaster for upgrades. Keep your eye on pkgng as the package repositories come up to speed and the supporting tools (portmaster, etc) mature their support for the new format.
People won't get that same sense trying it now. FreeBSD has gone so far towards the random bloated complexity of linux distros that you really don't feel much of a difference at all. To get that feeling now someone would need to try out one of the other BSDs.
I may actually consider dumping Debian for FreeBSD 10.
I've never been totally happy with Linux after moving off "proper" UNIX machines. I had a FreeBSD 4.4 machine floating around for years which I was rather happy with but drifted off to Linux-land primarily due to convenience when it came to Flash and audio.
So many compelling reasons to switch back to FreeBSD now.
I ask because Debian has a FreeBSD "port". That is, it offers the Debian userland on top of the FreeBSD kernel.
So, depending on what you're looking for, you might be able to gain access to the best of both worlds.
If you're after the FreeBSD experience (i.e. the community, the BSD command line utils, ports, and the preference for permissive licenses), then I guess Debian/kFreeBSD really isn't of any interest to you.
I've used FreeBSD and before that Gentoo (which has a package manager, portage, influenced by BSDs ports system) for more than a decade, and I've never understood the appeal of apt or the other Debian tools. In my experience, they just don't work as well as ports, constantly require adding additional repositories (because the official repository is missing some relatively popular package for who knows what reason) - which may or may not conflict with others I have -, and in general, are just more work than ports, portage, or MacPorts.
Inflicting apt on a system with a superior package management system seems like a sysadmin's bright idea - having no experience with ports or other package managers.
I've used apt on several systems - Maemo, Debian, Ubuntu, OS X (as fink), and always found it to be one of the weakest package managers (I've even had better experience with yum/RPM).
So how do you use ports in practice? Do you use sources or binary packages? Which management solution do you use, or do you just use the make files? I am constantly thinking about revisiting BSD, but in contrast to your experience I found the apt package solution to work very well and just be better.
I install everything from source. Except for thing like desktop environments, building from source is a non-issue on modern hardware. It also gives me some confidence in the binary compatibility of the packages I have installed.
pushd /usr/ports/*/$PACKAGE ; sudo make install clean && popd
I use FreeBSD on a desktop at home and for a personal web server. I'm not performing large scale deployments (but if I were, I'd probably write a port for my application, define my dependencies, and install it just like anything else).
In your example, however, the failure of `make install clean` will put you back in the original directory and not in the port's directory where you probably want to be to debug the failure. My original example keeps you in the port's directory in the event of installation failure.
Personally, I couldn't anymore handle the way ports asks for configuration options for every package that has configurable options. I'm spoiled by the "sane defaults" stance of better Linux distros like Arch.
which runs `make config` on the package and all dependencies before installing. It's the best of both worlds IMO -- the port will build unattended and you still have a chance up-front to skim the available options for things you need.
Either set BATCH env variable or use portupgrade/portinstall with -c or -C flags. The latter gathers all the dependencies of a given port and let's you configure them up front, and then the compilation and installation goes without any interruptions.
Run "make config-conditional" before everything for all tasks.
Run "make config" before everything for all tasks.
From my perspective (I'm not the GP), I will be using a custom configuration management system that I wrote back in 1999. It's. Like puppet but ssh based, written in sh and standard Unix tooling. It doesn't use a DAG so you have to order dependencies carefully.
That will pull binary packages from ports builds on another machine and install and configure them.
Port updates are a lot nicer now we have poudriere and pkgng - I haven't had a "pkg upgrade" break anything in months, and that was prior to automatic shared library tracking and just needed a "pkg install -Rf lang/perl" to fix.
e.g. the latest entry in UPDATING is for any port depending on converters/libiconv. Using portmaster or portupgrade requires querying the package database for the list of depending ports, force-deleting libiconv and then force-rebuilding from the previously saved list. With pkgng it's a case of "pkg upgrade && pkg autoremove".
I've really wanted to give FreeBSD a 100% solid shot. With this release I may try uploading my own FreeBSD image to a Xen VPS provider (probably Linode).
With that being said, I feel like I may be a spoiled little GNU user. There's plenty of times where I end up on a BSD system, and I try to use some sort of GNU-idiom in a command-line utility and I end up really really confused and unsure of how to bend it to my will. I think GNU sed is one of the first ones to come to mind, but there are definitely other utilities where the flags don't match up or don't even exist.
The next time that happens, try running the command again, but prepend a 'g' (so gsed, gawk, etc). Most BSD systems have the GNU versions of utilities present in their ports systems, and many come with the gnu coreutils installed, g-prefixed.
Just right now happen to help old $work with their 4.11-STABLE FreeBSD station, not touched since 2005 .. amazing technology, love it!. Still working, and while compiling ancient stuff from ports tree, am writing this comment from Konqueror 3.3.2 from 2004 . Thank you FreeBSD people!
Capsicum is still work in progress and worked on. Since FreeBSD 9, it has undergone a lot of internal design changes (capabilities are now embedded in the filedescriptors instead of being standalone structures), and API changes.
Yet another API change is undergoing to make the code more future proof (currently, you can have only 64 different capability rights, which is not enough), but it's happening out of tree. There are also new libraries to ease applications developpement.
Capsicum is not yet in a real production state. It's a big project and it needs a lot of thoughs to get it right. I don't know if it will get in FreeBSD 10, I'm not a freeBSD guy, but you can be sure there are still a lot of work dedicated to capsicum ! After the basic kernel API and libs has been stabilized, it will still need work to convert applications to capsicum before you can consider capsicum as a deployed security mechanism in FreeBSD.
thats because it was already merged in freebsd 9
.. for freebsd 10, they are polishing it..
but it works since 9..
For me this is another thing that are very appealing!
if you mix capsicum with jails, zfs, geli, pf.. you can have the most secure box in the world..
all of this amazing technology directly integrated with the kernel, and being maintained in the mainstream freebsd.
no thirdy-parties involved
Does anybody know how RDRAND is being used in FreeBSD 10 ?
is RDRAND somehow mandated so that it must be used, I mean why are both Linux and BSD both thinking that this is such a swell feature that must be implemented ?
A lack of entropy sources on some kinds of hardware is a real problem, and buggy attempts to work around it have resulted in defective, easily factorable keys being used in the wild on equipment like Juniper SRX gateways: https://factorable.net/weakkeys12.extended.pdf
Have never used FreeBSD, and am curious about using it on my laptop -- so an honest and perhaps naive question for people who do use it as their main system:
Does it JustWork on the majority of average-user things, like connecting to your Wi-Fi access point, displaying your desktop at its maximum resolution without crying, playing your multimedia files, etc? Ubuntu gets this just right, providing a perfect balance between core technologies for developers, and ease of software installation for common activities like, say, watching a Youtube video.
Support for 500 virtualisation technologies and no easy support for, say, playing mp4 files is going to make me not want to use it on my laptop. Then again, the average user might not exactly be who FreeBSD is targeting for their software.
I've been using FreeBSD as my main system since version 9.0 (before that ~8years of using linux - slack, arch, crux, suse, debian).
Graphics: intel and nvidia will work fine (well, except you can't switch back to text mode once you load intel module - will be fixed, just not a priority).
Wifi: works flawlessly.
Multimedia: I use mplayer/emacs. No difference from linux.
Flash: Works, sometimes hangs (once a week? I'm use youtube a lot). You will have to remember to manually update your plugins (running nspluginwrapper), if you don't - expect pain.
Wine: same as linux, depends on your graphics card support (if playing games).
User friendliness: If you can get around in archlinux, you will manage just fine with FreeBSD.
Not a technical person/don't like to play with your system? I highly recommend giving PC-BSD a look - imho it is comparable (slightly worse) to openSUSE - you can configure almost everything with a mouse. And the system is fast.
Suspend/hibernation: never managed to make it work (thinkpad e320).
First of all, I love to tweak. FreeBSD is only *nix I tried that worked well no matter what I changed and worked AS I EXPECTED IT WOULD!
Once you configure your system you are done. Expect it to behave properly and not require any fixes because you updated at a wrong time etc. (I hated ubuntu for it - I had to roll back packages manually THREE TIMES! - yes I am spoiled by FreeBSD :D ).
You can use ZFS as your root partition.
There is almost no documentation and tutorials in the web (compared to linux), the reason for that is EVERYTHING IS DOCUMENTED. Just RTFMan/Handbook. It takes a while to get used to it if you used linux before.
It is definitely not something likely to "just work" on your laptop, a la Ubuntu. I absolutely love FreeBSD and enjoy learning about it and using it and digging into its internals, but it is not intended to be a replacement for Ubuntu. For example, the installer only installs FreeBSD itself, which does not include any GUI components such as an X server.
I don't really see this as a failing of FreeBSD at all- it has a very specific scope and the developers are focused on fulfilling the requirements of that scope with the highest degree of quality and architectural coherence that they can muster. However, people looking for an Ubuntu replacement that don't want to mess around on the command line or edit text files for system configuration are going to be disappointed.
This isn't to say that it can't do all of the things that desktop-focused Linux distros can do. It has a really nice system for building third-party open source software (the ports system), or you can just install prebuilt binary packages with its package manager. So, you can pretty easily get X and your preferred desktop or window manager and your favorite apps on there, but it requires learning how to use ports (and therefore, building everything) or figuring out how to install the binaries from the command line with the package manager.
Having said that, you might want to try out PC-BSD. PC-BSD is a desktop-oriented system that uses FreeBSD as its core. My understanding is that every PC-BSD release is tied to a corresponding FreeBSD release, and what you are doing when you install PC-BSD is installing a stock FreeBSD system plus a graphical interface (including an X server, the desktop of your choice, and a graphical package manager), using a nice, simple GUI installer that attempts to "just work" and do the right thing with minimal input from the user.
You can think of the relationship between PC-BSD and FreeBSD as analagous to the relationship between Ubuntu and the Linux kernel, in the sense that PC-BSD builds a complete desktop system by shipping a bunch of integrated higher-level components layered on top of an upstream core system. FreeBSD is a standalone project focused on providing that core system, and PC-BSD is more of a distro that brings together a bunch of other pieces to build a complete desktop system around that core.
I also get the impression (someone please correct me if I'm wrong, or go into more detail if I'm right) that there's a high degree of commonality between people working on the two projects, and that there is a pseudo-official relationship whereby PC-BSD is considered by many people to be the blessed desktop version of FreeBSD.
Laptops aren't really where FreeBSD shines. It's possible, but linux is clearly more advanced on that front. I'm not sure many people bother with it, I certainly don't. (I run a FreeBSD VM on a Windows host)
* Support for things like Wifi and suspend isn't a given at all (I never had reliable wifi on linux either, but I think I'm an outlier in that).
* Nvidia release official drivers for FreeBSD, which tend to work fine. For the rest, you're on your own. I'm not sure of the state of Intel drivers, haven't tested for some time.
* Audio tends to just work. The lack of pulseaudio actually makes things simpler than linux.
Originally, the biggest was legal: When OSSv4 first came out (2002), it was not free software, so it could not be included in Linux. In 2007, it was released under the GPL, so that went away. However, this created animosity towards it from the kernel devs.
That explains OSSv4, but what about v3? OSSv3 was the only sound system in Linux 2.4 and earlier; why didn't they continue developing that? There are various criticisms of it; that it doesn't map well to modern audio devices. I am under the impression that a lot of the design criticisms of OSSv4 are actually against OSSv3, and they haven't bothered to learn OSSv4; but I have no real citation for this.
The OSS people don't really work with the Linux people, so the Linux devs don't want to invest a lot of time in someone else' code. This makes even more sense when we consider that Lennart Poettering claims there are only about 3.5 paid people working on sound in Linux--they would of course be fairly heavily invested in ALSA.
IMO since OSSv4 was proprietary for a while, the kernel folks invested most of their efforts developing ALSA, so by the time OSSv4 opened up and became a viable choice, ALSA had much better sound card driver support.
Another big issue is that OSS doesn't support MIDI or USB sound card input, which is a pretty huge functionality gap for people who are using those features.
It is a long story, that I do not remember entirely and corretly, but it was mostly politics...
Part of it was because OSSv4 was briefly not open source, and this pissed off lots of people, when it became open again, there was some political fights (that I don't remember the reasons), and there is some technical details of OSSv4 that irritate the kernel people (like the fact that instead of being entirely on userland it rely on Kernel space to reduce latency, specially for games, and the kernel people say they believe it should be userland only).
If you want to use BSD on a laptop, your best bet is PC-BSD. I love using FreeBSD on my laptop, but it definitely didn't "just work," you definitely have to tinker with it. PC-BSD is based on FreeBSD but attempts to "just work" in the way you are looking for.
Can't comment on FreeBSD but I run OpenBSD on my laptop and for me it "just works" (wifi, trackpad, display, etc.) but I did have to swap out the stock wifi adapter for a supported one. What doesn't work is suspend/resume. I haven't tried the latest -current yet though, which I did recently install on my desktop and finally got native resolution on my dual 30" monitors.
That said, things I don't do on my computer include playing games, watching videos and listening to music, so my definition of "just works" may not be the same as yours.
For a laptop, if you're looking for a "just work" solution, I would say forget it. Automagic full support for touchpad, energy management and such is not there yet. Not too surprising, even linux still has trouble here and there with laptops, but I think trying it in that context would make you dislike freebsd for the wrong reason.
But on a server or even a desktop computer, it's really great
I don't think you should use it on your laptop. See, the thing is:
>Does it JustWork on the majority of average-user things
Not on most hardware. The problem is basically drivers, it's always been drivers, I doubt it'll ever stop being drivers. When it comes to off-the-beaten-path OS's like BSD, Haiku, etc (maybe even Linux), it really makes sense to buy a machine with it in mind. That way you can look at specs and make sure all of the hardware is fully supported. Unfortunately it's not rare that even one unsupported thing can become a huge pain in the ass.
So you can put it on a* laptop, but I wouldn't put it on your current laptop unless you've done plenty of research and you're sure everything is supported.
And it's become my opinion that new and unpopular OS's can provide a better user experience by recommending or even targeting a two or three series of hardware (e.g. Samsung Chromebooks) where everything should work out of the box. Which isn't to say a user couldn't install the OS on something else, but a set of preferred hardware never hurt OS X, and even hackers prefer to have something available that "just works". Especially when developer resources are limited, it could be an advantage to prioritize in a way that manages to deliver a very good user experience to the people who are willing to make a little investment to use the OS. As the project grows, the list can get larger, it's not like you're limiting yourself forever.
ps: FreeBSD actually has in my experience (~2 years ago) a very nice audio system (OSS4), so playing mp4s should be no issue.
If you are looking for a pragmatic operative system, freeBSD is going to be at the bottom of the list thanks to it having the hardest licensing requirement for included software projects.
Ubuntu include anything from proprietary freeware blobs, to GPL, to permissive licensed software. So long the inclusion improves the practical use, it is included. The more ideological free software operative systems excludes the proprietary freeware blobs, but keeps the GPL licensed and permissive licensed software. FreeBSD excluded both proprietary freeware blobs and GPL licensed software, and only uses software that is permissive licensed accordantly to the OSI standard. This methodology also cover driver support for hardware, as they won't port a linux driver to BSD if the linux driver is GPL.
However, most commonly used GPL software has an permissive alternative, so if you are lucky, using those alternative won't impact you too much. On the server side, I would think that is more true than for the laptop.
This argument misses the distinction between the FreeBSD "base system" and the whole of the FreeBSD project, which includes more than 20,000 applications with all matter of licenses -- permissive, copyleft, and proprietary. Taken as a whole, FreeBSD certainly does not exclude proprietary or GPL software.
The base system consists of the kernel, toolchain, shell, and standard daemons. For the base system it is true that we prefer permissively licensed components. Today there are a few components that are not permissively licensed, and there is a plan with credible replacements for them.
It would be interesting to compare say Debians repositories (all of them), and to the FreeBSD Ports collection. I do not know how much drivers and practical software packages that would differ between them. PF is clearly a killer-app of bsd, and maybe systemd on the linux side. Would make for a very interesting read if done properly without too much political bias.
However, I don't think it will help the parent post. Doing a base install, and wading through all the contrib packages and build a custom operative system is not the most practical thing to do. There are a reason why Debian has so many derivatives that picks and chose between the 40,000 applications laying around in debian repository. This is (in my view) the primary reason why Ubuntu has more installs than Debian, even if debian has more total available packages.
(As a side note: Thanks to your post I went and looked at ports collection and noticed that freeBSD do include many ported linux drivers through ports collection. The statement that I read earlier about porting was thus wrong, as BSD developers will port linux drivers to freeBSD - just not for the freeBSD base install. They also include a linux emulator which makes a linxu vs bsd comparison a bit more muddy.)
I'll agree with you that choosing individual software packages can be a daunting task for someone who's just looking to set up a single laptop or desktop as an end user.
In the FreeBSD world the PC-BSD project (http://www.pcbsd.org) provides an operating system focused on the end-user experience, with a convenient "out-of-the-box" configuration. They track FreeBSD development closely and in general use exactly the same source - primarily changing configuration and tuning options.
From their website: PC-BSD is a desktop operating system based on FreeBSD. Rather than having the user build their own environment from the base operating system, PC-BSD aims to make the FreeBSD experience easy and achievable for the average "casual" computer user.
When the FSF says a license is GPL-compatible, what they mean is, "You can legally combine software under this license with software under the GPL to produce a new combined product, provided that new product is distributed under the GPL."
Assuming that FreeBSD's maintainers want to keep their code under the BSD license, they'll be wanting something more permissive than the FSF's "heads I win tails you lose" version of compatibility.
Yes; but if they want to release the BSD kernel as a whole under the FreeBSD license, then they already cannot incorporate code that has any other license whatsoever. For example, they wouldn't accept my patch under the hypothetical license "you can do whatever you want with this code except shoot bunnies". If they did, FreeBSD users couldn't use FreeBSD to shoot bunnies.
Am I missing something about the BSD kernel licensing social dynamic?
It's not about patches. FreeBSD drivers generally shouldn't be patches; they should be loadable modules so you can use them without recompiling the kernel.
Now if you changed your hypothetical so that it's not a patch but a separate module that compiles to its own distinct binary, and your hypothetical license were expanded to include a second clause, "Anything that links to binaries built from this code must inherit this license," then we'd be talking about a situation that replicates the issues with making use of GPL code in projects that use more permissive licenses.
The CDDL is a file-scope weak copyleft license, and is (broadly) less restrictive than the GPL. As bunderbunder pointed out FreeBSD is not able to include GPL code, because the GPL is not compatible with the distribution terms for the kernel.
The CDDL is generally less restrictive in terms than the GPL; its not GPL-compatible, which, given the wide array of software under the GPL and the GPLs more intense restrictions make it hard to use in many places where GPL software is in use, which perhaps makes it seem restrictive in an environment where there is an unavoidable commitment to GPL software in some role which would create a requirement GPL- or GPL-compatible software, but that's a result of the of the fact that the GPL is restrictive, not the CDDL.
(The CDDL is decidedly not permissive, of course, but its a far cry from being more restrictive than the GPL.)
How is the CDDL more restrictive than the GPL ? As far as I can tell, ZFS can be included because the CDDL imposes less restrictions on the final distribution (the non-CDDL parts don't have to abide by the CDDL license, which would be the case with the GPL).
You're comparing apples and oranges though- Ubuntu is a distribution that attempts to be a complete desktop OS, and FreeBSD is a single project that provides the kernel plus the required low-level userland of an OS.
Complaining that FreeBSD has strict licensing requirements is like complaining that the Linux kernel has strict licensing requirements- they don't, they just have project-wide standards for licensing. Ubuntu (or Linux distros in general, or PC-BSD for that matter) is less of a project and more of a collection of components from different sources, so by definition it's not going to attempt to impose its own licensing requirements on those third parties.
Think of it like this: if the Linux kernel project evolved in a different way, such that the project as managed by Linus wasn't just the kernel but also the required low-level userland (libc, /bin/ls, etc.), then you'd end up with something that closely resembles FreeBSD. No one would use this hypothetical "Linux kernel plus low-level userland" project by itself, they would install it and then install whatever else they wanted from other sources on top of it. There would still be all sorts of distros that made it easy to do this. Ubuntu would still exist, except structurally it would more closely resemble the relationship between PC-BSD and FreeBSD.
i think you are switching the cards here..
the elitist license is GPL, not BSD..
theres no license more free than BSD (except MIT maybe?)
and the reason they cant use GPL, its because GPL dont allow no GPL licenses with it... so what they should do? change all their more liberal license for GPL?
One of the good reasons to like BSD´s is because of its licence, not the opposite
> So essentially - unless you want to start building packages and maintaining repos - pkgng is at this moment _useless_.
Well since that is the point of pkgng I'm not sure what you're griping about. The effort of it? poudriere allows pretty trivial building and automated repo generation. Is it a little more effort than typing apt-get update? Yup. But you aren't at the whim of repo maintainers on getting new packages in(like most stale Linux distros), or with ideal compile time options, or trying to find a repo that has the packages you're seeking.
>  - providing many packages and updates like in the linux distros world, not just "set it and leave it" as they do with the current repos.
With pkgng, you control when the repo is updated and what is updated. It's negligible effort to do so since it's a product of the ports system. I'm not sure what distro you've been using that leaves you with such pie in the sky attitude but it isn't one I'm familiar with. The enterprise distro are all horribly out of date, the bleeding edge are inappropriate for production use, and the in-betweens give you problems from both ends.