FreeBSD expands activities as funds flow in(itwire.com)
itwire.com
FreeBSD expands activities as funds flow in
http://www.itwire.com/business-it-news/open-source/59658-freebsd-expands-activities-as-funds-flow-in
12 comments
This is great to hear. I'm a huge fan of the BSD OS's, but it's been concerning that lately FBSD seemed to be falling out of favor. Unfortunately, many 'unix' people these days have only ever worked with Linux distros. While the distro model does provide a novel approach to packaging an OS that has it's strengths, there are some downsides. I love Linux for the suppor, the rapid release cycles, and the many different approaches to things(e.g. init systems). However, sometimes I have a project that requires an OS that just works as cohesive product(eg. file server or network appliance) and FreeBSD typically fits that bill for me. The support is much more limited, but the things it does support are almost always rock solid.
The first time I really had to use a BSD (OpenBSD) system for more than some simple tasks, I was blown away. There's a definite feel of design, as opposed to a large set of features and interfaces that happen to work together to varying degrees as in Linux.
And the man pages. Oh, how wondrous they were. This first thing I had to do was learn to NOT google for how to accomplish something, but just read the man page. Often, there's not much on google about something because there was no need for someone to document how they accomplished it, they just did what the man page said and it worked.
In linux, the man pages are generally skeletons outlining some flags and what something might support. In BSD (or at least OpenBSD) for core OS items, they are canonical. Compare:
That said, I still mainly use Linux, specifically RHEL and derivatives, specifically because I think the enterprise Linux distros have a better support model for enterprise environments, where multiple machines need to be kept up to date or in sync, and you need to deploy identically (and repeatably) to systems.
Frankly, I'm surprised there's not a alternate, distro model for FreeBSD that's aimed at the enterprise to address these issues (or if there is, it's not popular enough for me to know of it). Maybe FreeBSD as an organization is coherent enough and does a good enough job at support for the distro in general that there's never been enough of push to really compete in the enterprise server market. Or maybe I'm just misinformed about how much BSD is in use in the enterprise. That's always a possibility.
And the man pages. Oh, how wondrous they were. This first thing I had to do was learn to NOT google for how to accomplish something, but just read the man page. Often, there's not much on google about something because there was no need for someone to document how they accomplished it, they just did what the man page said and it worked.
In linux, the man pages are generally skeletons outlining some flags and what something might support. In BSD (or at least OpenBSD) for core OS items, they are canonical. Compare:
http://linux.die.net/man/8/ifconfig
http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig
That said, I still mainly use Linux, specifically RHEL and derivatives, specifically because I think the enterprise Linux distros have a better support model for enterprise environments, where multiple machines need to be kept up to date or in sync, and you need to deploy identically (and repeatably) to systems.
Frankly, I'm surprised there's not a alternate, distro model for FreeBSD that's aimed at the enterprise to address these issues (or if there is, it's not popular enough for me to know of it). Maybe FreeBSD as an organization is coherent enough and does a good enough job at support for the distro in general that there's never been enough of push to really compete in the enterprise server market. Or maybe I'm just misinformed about how much BSD is in use in the enterprise. That's always a possibility.
And the man pages. [...] This first thing I had to do was learn to NOT google for how to accomplish something, but just read the man page.
http://www.freebsd.org/doc/en/books/handbook/
You just pick the section of interest (or sit down and start from the beginning) and.. start reading. And when you're done, you understand the overall design of the system, its processes and system tools. With GNU/Linux, I quite often feel that when there's a problem, I'm looking for a quick fix. (Granted, it may simply be due to my limited experience / few years of exposure.)
In any case, I do thoroughly recommend everyone dabbling with fbsd not to underestimate the power of fbsd's documentation, and the uniformity (and the resulting empowerment of the system administrator because of this) of the overall system. As I understand it, OpenBSD is very much alike in that sense.
"Linux doesn't have man pages. It has boy pages." -- Glen Pritchett.
I've always had the strong preference for BSD documentation as well. But you know what's crazy? The guy who coordinates the Linux man-pages project, Michael Kerrisk, is definitely one of the greatest technical writers out there. His book "The Linux Programming Interface" is fantastic.
It'd be interesting to know why the BSD man pages are so much better.
It'd be interesting to know why the BSD man pages are so much better.
For OpenBSD at least, I'm pretty sure the practice of only accepting code patches that have accompanying man page patches when it changes behavior has something to do with it.
> Note: One the reasons the OpenBSD ifconfig man page is so big is because on OpenBSD ifconfig does the job of multiple Linux utils, because it makes sense to have ifconfig control all the interface state.
https://linux.die.net/man/8/ip
https://en.wikipedia.org/wiki/Iproute2
https://linux.die.net/man/8/ip
https://en.wikipedia.org/wiki/Iproute2
I was aware of iproute2, but wasn't aware the coverage ip had for features. That is indeed much better than ifconfig (feature wise), but I'm not sure if how indicative that man page is of the man pages on Linux in general, so it may just point out a poor example on my part.
Do you know if iproute2 if it supports STP configuration? I used brctl in the past to configure that, and it's something I would expect in an interface configuration tool (although maybe not a command named "ip"). I don't imagine that would be hard for them to add in if not though.
I think a better example of my point regarding man pages would be CARP[1]. In my experience where Linux has really lacked in man pages is concepts. The BSDs will offer refer you to man pages that aren't for any one command or file, but for a system or feature to explain it in general.
See also ipsec[2] for a description of the protocol, and aac[3] for a description of their driver implementation for Adaptec "FSA" family of RAID cards, and documentation on how to work with bluetooth[4] at the kernel level on their platform. Really, most of section 4[5].
[1]: http://www.openbsd.org/cgi-bin/man.cgi?query=carp
[2]: http://www.openbsd.org/cgi-bin/man.cgi?query=ipsec
[3]: http://www.openbsd.org/cgi-bin/man.cgi?query=aac
[4]: http://www.openbsd.org/cgi-bin/man.cgi?query=bluetooth
[5]: http://www.openbsd.org/cgi-bin/man.cgi?query=(4)&apropos...
Do you know if iproute2 if it supports STP configuration? I used brctl in the past to configure that, and it's something I would expect in an interface configuration tool (although maybe not a command named "ip"). I don't imagine that would be hard for them to add in if not though.
I think a better example of my point regarding man pages would be CARP[1]. In my experience where Linux has really lacked in man pages is concepts. The BSDs will offer refer you to man pages that aren't for any one command or file, but for a system or feature to explain it in general.
See also ipsec[2] for a description of the protocol, and aac[3] for a description of their driver implementation for Adaptec "FSA" family of RAID cards, and documentation on how to work with bluetooth[4] at the kernel level on their platform. Really, most of section 4[5].
[1]: http://www.openbsd.org/cgi-bin/man.cgi?query=carp
[2]: http://www.openbsd.org/cgi-bin/man.cgi?query=ipsec
[3]: http://www.openbsd.org/cgi-bin/man.cgi?query=aac
[4]: http://www.openbsd.org/cgi-bin/man.cgi?query=bluetooth
[5]: http://www.openbsd.org/cgi-bin/man.cgi?query=(4)&apropos...
More addon tools simply proves the point.
Task / BSD / Linux
set ip / ifconfig / ifconfig or now "ip" which is extremely confusing
wifi / ifconfig / iwconfig
speed / ifconfig / miitool or ethtool
duplex / ifconfig / miitool or ethtool
vlan / ifconfig / vlan
wol / ifconfig / miitool or ethtool
bridge / ifconfig / brctl
link aggregation / ifconfig / flags while loading module OR use distro network config scripts and restart all networking or reboot server
Want find out which nic is occupying ethX perhaps for tuning or scripting etc?
Linux = complicated, by distro/version
FreeBSD = nic by device eg em0
Task / BSD / Linux
set ip / ifconfig / ifconfig or now "ip" which is extremely confusing
wifi / ifconfig / iwconfig
speed / ifconfig / miitool or ethtool
duplex / ifconfig / miitool or ethtool
vlan / ifconfig / vlan
wol / ifconfig / miitool or ethtool
bridge / ifconfig / brctl
link aggregation / ifconfig / flags while loading module OR use distro network config scripts and restart all networking or reboot server
Want find out which nic is occupying ethX perhaps for tuning or scripting etc?
Linux = complicated, by distro/version
FreeBSD = nic by device eg em0
> Linux = complicated, by distro/version
Most Linux distros are adopting consistent naming schemes, using biosdevname algorithm, e.g.
https://fedoraproject.org/wiki/Features/ConsistentNetworkDev...
> More addon tools simply proves the point.
I was only showing that comparing Linux’s ifconfig with BSD’s ifconfig is not fair, not really making any point.
I don’t see how this is all that confusing though, you get ip for managing routing and iw/ethtool/etc for managing interfaces or creating interfaces on lower networking levels or device level. It’s just different.
Most Linux distros are adopting consistent naming schemes, using biosdevname algorithm, e.g.
https://fedoraproject.org/wiki/Features/ConsistentNetworkDev...
> More addon tools simply proves the point.
I was only showing that comparing Linux’s ifconfig with BSD’s ifconfig is not fair, not really making any point.
I don’t see how this is all that confusing though, you get ip for managing routing and iw/ethtool/etc for managing interfaces or creating interfaces on lower networking levels or device level. It’s just different.
Two reasons I recently switched to FreeBSD on my home servers, Dtrace and ZFS. In GNU/Linux I would need sort combination of strace,mpstat,ltrace,vmstat,iostat etc.. to find out the the things that a simple Dtrace script can tell me and also without dramatically affecting a running daemon process as the ptrace* system calls do.
Linux will soon have btrfs, which is as good as (if not better than) ZFS.
Also Dtrace & ZFS originally come from Solaries, so they are not FreeBSD projects. The only reason they do not work on Linux is because of license problems which Sun created.
Also Dtrace & ZFS originally come from Solaries, so they are not FreeBSD projects. The only reason they do not work on Linux is because of license problems which Sun created.
>Linux will soon have btrfs, which is as good as (if not better than) ZFS.
btrfs does not even try to solve the problem I want zfs for; snapshots over the network.
You see, when you deal with a large amount of storage (especially if you deal with that storage as block devices that run arbitrary filesystems, and not just files on a filesystem) the bottleneck for backups becomes disk bandwidth, not network bandwidth, so things like rsync don't help much.
ZFS snapshots over the network? those help rather a lot. Unlike rsync and stuff, it saves me disk bandwidth, not just network bandwidth. Unlike inotify-based systems, I don't need to have knowledge of the filesystems I'm replicating.
(I know I harp on this a lot... I just want to point out that btrfs, no matter how good it is for the problems it attempts to solve, isn't even trying to solve the problem I need ZFS for.)
btrfs does not even try to solve the problem I want zfs for; snapshots over the network.
You see, when you deal with a large amount of storage (especially if you deal with that storage as block devices that run arbitrary filesystems, and not just files on a filesystem) the bottleneck for backups becomes disk bandwidth, not network bandwidth, so things like rsync don't help much.
ZFS snapshots over the network? those help rather a lot. Unlike rsync and stuff, it saves me disk bandwidth, not just network bandwidth. Unlike inotify-based systems, I don't need to have knowledge of the filesystems I'm replicating.
(I know I harp on this a lot... I just want to point out that btrfs, no matter how good it is for the problems it attempts to solve, isn't even trying to solve the problem I need ZFS for.)
> btrfs does not even try to solve the problem I want zfs for; snapshots over the network.
This a recent Ubuntu system (ie not using development trees etc)
This a recent Ubuntu system (ie not using development trees etc)
$ btrfs send --help
usage: btrfs send <command> <args>
btrfs send [-v] [-i <subvol>] [-p <parent>] <subvol>
Send the subvolume to stdout.
$ btrfs receive --help
usage: btrfs receive <command> <args>
btrfs receive [-v] [-i <infile>] <mount>
Receive subvolumes from stdin.Ooh. thanks. this post is probably the most useful bit of information I've read this month. Hm. I will have to research more, but this might... change things significantly. I mean, it's still a newish feature, not something you want for backups, but between that an bcache, Linux looks like it might deserve another look, storage-wise.
At <company I work for, which owns pfSense> we use ZFS for exactly this. Functional, always 'on' backups to the hosting center next door (we have some nice single-mode fiber running to our cabinet there.)
> Linux will soon have btrfs, which is as good as (if not better than) ZFS.
It may be awesome, but I'd say "soon" is a pretty optimistic timeline.
Our testing pretty conclusively demonstrated that btrfs was still a long way from production-ready; We've seen numerous problems with deadlocks; Filling up a filesystem pretty much ruins it forever -- And these are not new problems.
It may be awesome, but I'd say "soon" is a pretty optimistic timeline.
Our testing pretty conclusively demonstrated that btrfs was still a long way from production-ready; We've seen numerous problems with deadlocks; Filling up a filesystem pretty much ruins it forever -- And these are not new problems.
Indeed, "soon" is taking a little longer than expected:
http://lwn.net/Articles/238655/
As far as I can tell, those forecasts have almost always come from outside the project. I don't recall Chris Mason ever saying that it's right around the corner.
In fact, searching for "soon" on the Btrfs wiki produces 0 results.
It's still a very active project, but there's still a lot of work to be done.
http://lwn.net/Articles/238655/
As far as I can tell, those forecasts have almost always come from outside the project. I don't recall Chris Mason ever saying that it's right around the corner.
In fact, searching for "soon" on the Btrfs wiki produces 0 results.
It's still a very active project, but there's still a lot of work to be done.
At this point, the amount of complete data losses I've seen on the LKML makes me wonder why anyone wants to promote BTRFS as being better than anything I would want to use for things approaching production.
I may be an old Solaris hand now but ZFS works. Now, not in the future, my home fileservers on FreeBSD have worked for ages and had no issues. Unlike the many complete losses on BTRFS on Linux that I see happening time and time again. SuSE might be promoting BTRFS, but objectively I can't agree with their decision.
I may be an old Solaris hand now but ZFS works. Now, not in the future, my home fileservers on FreeBSD have worked for ages and had no issues. Unlike the many complete losses on BTRFS on Linux that I see happening time and time again. SuSE might be promoting BTRFS, but objectively I can't agree with their decision.
> Linux will soon have btrfs, which is as good as (if not better than) ZFS.
ZFS is stable and released. Pretty sure that makes it instantly "better" than btrfs right now.
ZFS is stable and released. Pretty sure that makes it instantly "better" than btrfs right now.
"license problems" ∈ "problems"
One thing I like about FreeBSD, and the BSDs in general, is that they don't suffer from such problems.
It's odd that Oracle (who now own Sun's IP) paid to develop a whole new filesystem (btrfs) for Linux instead of just changing the licensing terms for ZFS. It would be nice to have a really good, Apache-licensed filesystem that could run across Linux, OS X, BSD, and Solaris.
One thing I like about FreeBSD, and the BSDs in general, is that they don't suffer from such problems.
It's odd that Oracle (who now own Sun's IP) paid to develop a whole new filesystem (btrfs) for Linux instead of just changing the licensing terms for ZFS. It would be nice to have a really good, Apache-licensed filesystem that could run across Linux, OS X, BSD, and Solaris.
Actually there is HammerFS. Porters welcome, I'd love to see it more widespread.
People who compare zfs and btrfs and even put them on the same level, are usually people who have no idea about neither of them.
Would you recommend a BSD VM for web development? That's my use for linux, and would love to try something new, FBSD has a good reputation.
FreeBSD is just fine for web development, and it runs great on VirtualBox if you want to try it. PC-BSD (the "Desktop" edition of FreeBSD) has live CDs and pre-installed VirtualBox and VMware images if you want to give it a try:
http://www.pcbsd.org/en/download.html
Where FreeBSD really shines though, is web deployment -- i.e, it's an awesome platform to deploy your webapps on once they're ready.
http://www.pcbsd.org/en/download.html
Where FreeBSD really shines though, is web deployment -- i.e, it's an awesome platform to deploy your webapps on once they're ready.
That's kind of a hard question to answer without knowing your definition and requirements for 'web development'.
First, keep in mind that some of the packages will simply not run on FreeBSD because it's often overlooked by developers. Same logic applies for technical support for applications that are running on FreeBSD powered machine.
You also will need to learn how port system works on FreeBSD and it might be a weird learning curve. Same applies for kernel patching/upgrading/etc.
First, keep in mind that some of the packages will simply not run on FreeBSD because it's often overlooked by developers. Same logic applies for technical support for applications that are running on FreeBSD powered machine.
You also will need to learn how port system works on FreeBSD and it might be a weird learning curve. Same applies for kernel patching/upgrading/etc.
The learning curve isn't too bad for FreeBSD. I primarily develop F#/.NET apps on Windows; I've used Linux occasionally for research over the past few years, and more recently, to try out the F#/Mono combination.
I decided to try FreeBSD last year and was able to learn enough in a week to do some basic development work with it. In fact, I submitted patches for Mono 3.0 and F# 3.0 to the FreeBSD ports tree:
http://www.freshports.org/lang/fsharp/ http://www.freshports.org/lang/mono/
The folks on the FreeBSD forums are also very helpful (and patient!) so if you do run into trouble, you'll likely find the solution by asking there.
I decided to try FreeBSD last year and was able to learn enough in a week to do some basic development work with it. In fact, I submitted patches for Mono 3.0 and F# 3.0 to the FreeBSD ports tree:
http://www.freshports.org/lang/fsharp/ http://www.freshports.org/lang/mono/
The folks on the FreeBSD forums are also very helpful (and patient!) so if you do run into trouble, you'll likely find the solution by asking there.
Ehh. I don't think it's too bad these days. Especially with tools like portsnap and portmaster(which are well documented in the handbook).
Investing in staff is a primary goal for the Foundation for 2013. The staff members who have been announced so far are Konstantin Belousov and Edward Tomasz Napierała, with announcements at http://freebsdfoundation.blogspot.com/2013/03/foundation-ann... and
http://freebsdfoundation.blogspot.com/2013/04/freebsd-founda... .
In the past the FreeBSD Foundation has sponsored quite a number of specifc projects; having technical staff members employed by the Foundation allows for new kinds of work to be performed. Operational tasks are one example, and include the release process, handling security issues, system testing, and maintaining project servers. Having Foundation-employed staff also provides ability to provide continuity to longer term projects that require smaller but repeated efforts.
In the past the FreeBSD Foundation has sponsored quite a number of specifc projects; having technical staff members employed by the Foundation allows for new kinds of work to be performed. Operational tasks are one example, and include the release process, handling security issues, system testing, and maintaining project servers. Having Foundation-employed staff also provides ability to provide continuity to longer term projects that require smaller but repeated efforts.
Guys if you've got some spare cash I recommend putting a bit towards having FreeBSD working flawlessly on a single well-defined desktop platform (e.g. thinkpad). It doesn't need to be fancy, but the little things like suspend-and-resume need to work correctly without tinkering. That way if someone wants to run FreeBSD, you give them a straightforward starting point. At the moment some FreeBSD fans reluctantly turn to linux for these reasons.
As a long time BSD user (laptop and server) who is always on the cusp of throwing in the towel, I have wanted this, chased for this and even posted on HN before.
The big issue for this is knowing that the chipsets will remain stable over time. My best guess is to piggy back on a big Fortune 500 purchasing department - that is the CTO for say Exxon wants the same damn chips in all his windows PCs for the next three years because it makes support a 1000 times easier. So he basically tells HP set aside enough chips and capacity for me and I will keep buying.
If we can piggy back on that - we can target a fixed platform.
So if there are any Fortune 500 CIOs here with a nice deal from HP, and anyone willing to pay in the range of 500 pa to keep a BSD developer in beer and roofing tiles please shout - I will do the admin if others show willing
The big issue for this is knowing that the chipsets will remain stable over time. My best guess is to piggy back on a big Fortune 500 purchasing department - that is the CTO for say Exxon wants the same damn chips in all his windows PCs for the next three years because it makes support a 1000 times easier. So he basically tells HP set aside enough chips and capacity for me and I will keep buying.
If we can piggy back on that - we can target a fixed platform.
So if there are any Fortune 500 CIOs here with a nice deal from HP, and anyone willing to pay in the range of 500 pa to keep a BSD developer in beer and roofing tiles please shout - I will do the admin if others show willing
This is a great idea! I think it would be a waste of time for FreeBSD to take the entire desktop market on -- Linux has been fighting that battle for years -- but it would be awesome if Dell/HP/Lenovo came out with a PC-BSD-based laptop with official support. (For those not familiar with FreeBSD, PC-BSD is the "Desktop" edition of FreeBSD.)
Another feature I'd really like to see the FreeBSD Foundation focus on this year is full support for Xen/KVM, with the specific goal of getting FreeBSD to be a "first-class" citizen on EC2. Interestingly, some folks from Microsoft are working on Hyper-V drivers so perhaps we'll see FreeBSD on Azure in the future.
Another feature I'd really like to see the FreeBSD Foundation focus on this year is full support for Xen/KVM, with the specific goal of getting FreeBSD to be a "first-class" citizen on EC2. Interestingly, some folks from Microsoft are working on Hyper-V drivers so perhaps we'll see FreeBSD on Azure in the future.
Dell/HP/Lenovo won't do that - the most they're likely to do is half-assed support for Linux. That's why it would be neat if FreeBSD to get themselves working solidly on a single platform, because fans would have a reliable option.
Recent thinkpads recognize FreeBSD as an OS, and then promptly have tons of issues with poorly designed ACPI.
On that note, what are the best laptops/netbooks out there for *BSD in terms of hardware support? I was thinking of doing what the grandparent comment was suggesting, but had trouble finding a list of (near) 100% supported machines.
When I looked at this six months ago the answer was thinkpads. But there is still oddness. I got a X1 Carbon which is a fantastic system once you get rid of the awful Windows setup it ships with but I ran out of time to mess around getting FreeBSD right and moved to ubuntu which is adequate.
FreeBSD is also participating in Google Summer of Code 2013, in case any students are considering applying to the program. The application deadline is May 3rd though (2 days from today), so if you are thinking about it you need to hurry:
http://www.freebsd.org/projects/summerofcode.html
http://www.freebsd.org/projects/summerofcode.html
The one place I'd like to see FreeBSD run better is on Amazon EC2. Last I looked at the effort, it was subverting the VM mode used for Windows EC2 instances to boot FreeBSD. Unfortunately, this means paying the Windows price for instances.
Yes - the Foundation is interested in ensuring FreeBSD works well in both virtualization guest and host capacities.
Newer EC2 instance types don't tie the Windows license fee to HVM mode and FreeBSD can be run on those, for no additional cost: https://aws.amazon.com/marketplace/pp/B00AA25MLK. The Foundation would like to see FreeBSD available on the other EC2 tiers without additional fees and is investigating alternate approaches there.
Newer EC2 instance types don't tie the Windows license fee to HVM mode and FreeBSD can be run on those, for no additional cost: https://aws.amazon.com/marketplace/pp/B00AA25MLK. The Foundation would like to see FreeBSD available on the other EC2 tiers without additional fees and is investigating alternate approaches there.
FWIW, while the AWS Marketplace only lists cc1.4xlarge, cg1.4xlarge, cc2.8xlarge, and hi1.4xlarge, my native-HVM AMIs also run on cr1.8xlarge, hs1.8xlarge, m3.xlarge, and m3.2xlarge.
The only instance types where you need to pay the Windows tax are m1., m2., c1.*, and t1.micro (although in some regions the Windows tax for t1.micro is free). Unfortunately, this set includes all of the smallest/cheapest instance types, and thus the ones people want to use most often...
The only instance types where you need to pay the Windows tax are m1., m2., c1.*, and t1.micro (although in some regions the Windows tax for t1.micro is free). Unfortunately, this set includes all of the smallest/cheapest instance types, and thus the ones people want to use most often...
I wasn't aware that Amazon had uncoupled the Windows license fee from HVM mode! If this is true, The FreeBSD Foundation should make sure EVERYONE knows about it -- getting FreeBSD to be a first-class citizen on EC2 is absolutely crucial if they want to increase their marketshare.
We have a preliminary version of pfSense running on EC2 (mostly to front Amazon's VPC offering.)
This is the only reason I'm still developing for a Linux target. Unfortunately it is a compelling reason.
[deleted]
Runs wonderfully on Rackspace Cloud. Their default images are legit too.
You can run FreeBSD in PV mode as well. Well, it will require installing in HVM mode, recompiling kernel (commands in terminal, commands not lines) and rebooting. FreeBSD 10.0 has better support of DomU and KVM Guest.
Wishlist: really looking forward for a proper binary package management (à la yum/apt) and long term releases!
A much improved binary package management system, known as "pkgng," is on the horizon. More information is available at https://wiki.freebsd.org/pkgng. Pkgng will feel very natural to anyone familiar with apt.
If you'd like an introduction to pkgng there's a video from BSDCan 2012 at http://www.youtube.com/watch?v=4Hxq7AHZ27I, or see the README at https://github.com/pkgng/pkgng/blob/master/README.md.
If you'd like an introduction to pkgng there's a video from BSDCan 2012 at http://www.youtube.com/watch?v=4Hxq7AHZ27I, or see the README at https://github.com/pkgng/pkgng/blob/master/README.md.
I'm looking forward to it!
You can try it on FreeBSD-CURRENT...It's really night-and-day better than it used to be. Less underscores, and it runs about 20-40% faster than the old one even when "adding" software compiled from source (portmaster -day is almost twice as fast).
I'm using this[1], but having problems finding a binary repo where to get pkgng and the packages "ports".
[1] - https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/10.0-HE...
[1] - https://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/10.0-HE...
Happy to hear. With the systemd-pocalypse looming in Linux land, we who love Unix need an alternative.
Some of us welcome systemd, and are sad that Ubuntu, for example, appear to refuse to use it.
Donations can go right here: http://www.freebsdfoundation.org/donate :-)
I don't understand. There are lots of alternatives.
- Aix
- HP-UX
- Solaris
- Tru64
- MacOS X
- QNX
Or do you mean you don't pay for your OS?
- Aix
- HP-UX
- Solaris
- Tru64
- MacOS X
- QNX
Or do you mean you don't pay for your OS?
How many of those closed-source Unix variants run the applications Linux users are familiar with?
The complaint was about UNIX alternatives.
Linux distributions are not even UNIX, just UNIX compatible.
Linux distributions are not even UNIX, just UNIX compatible.
"BSD is what you get when a bunch of Unix hackers sit down to try to port a Unix system to the PC. Linux is what you get when a bunch of PC hackers sit down and try to write a Unix system for the PC"
"BSD people do what they do because they love Unix. Linux people do what they do because they hate Microsoft." --Theo de Raadt
> Linux distributions are not even UNIX, just UNIX compatible.
Depends on how you define "UNIX". If you define it as "Derived from the V6 codebase", then I'm pretty sure a number of the OSes you mentioned don't qualify. If you define it as "Legally able to use the trademark", then you miss a lot of OSes that work just fine with POSIX-compatible software, such as FreeBSD, and include z/OS, which is just perverse.
Depends on how you define "UNIX". If you define it as "Derived from the V6 codebase", then I'm pretty sure a number of the OSes you mentioned don't qualify. If you define it as "Legally able to use the trademark", then you miss a lot of OSes that work just fine with POSIX-compatible software, such as FreeBSD, and include z/OS, which is just perverse.
I was referring to the trademark.
For those interested in FreeBSD, a couple of additional links you might enjoy:
Installing FreeBSD on Raspberry Pi:
http://blog.khubla.com/?p=18
Android on FreeBSD:
http://forums.freebsd.org/showthread.php?t=37527
Installing FreeBSD on Raspberry Pi:
http://blog.khubla.com/?p=18
Android on FreeBSD:
http://forums.freebsd.org/showthread.php?t=37527
I absolutely adore FreeBSD. I work in linux these days because it's easier to bundle and distribute an upgradeable (binary distribution) linux appliance. I will run back to FreeBSD as soon as possible.
Once pkgng is available in a release pkgng will really improve the binary upgrade case, and the multiple repository support will also be of interest to anyone deploying an appliance using a number of stock packages and a few custom ones.
This, plus compatibility for the low-cost non-defenestrated EC2 instances will finally provide a realistic alternative to the huge farms of Ubuntu currently haunting AWS.
I'm not sure what the challenges involved are since I'm just a .NET guy who uses a debian home server, but I would switch to FreeBSD instantly if I could get utf-8 support in my irssi.
Sometimes I felt that the FreeBSD-Linux situation is similar to Python-Ruby.
FreeBSD/Python is more ... stable-ish and the community is calmer (or probably more mature) but the development is not as fast-pace as the Linux/Ruby counterpart.
FreeBSD/Python is more ... stable-ish and the community is calmer (or probably more mature) but the development is not as fast-pace as the Linux/Ruby counterpart.
That analogy doesn't really hold, since Python is more popular than Ruby, while FreeBSD is much less popular than Linux.
I'm surprised. I see more Ruby these days (all the online learning courses i.e.: codeacademy, etc).
Where I live, you won't have trouble finding Rails developers but not so much when it comes to Python.
Github is filled with probably more Ruby than Python.
Where I live, you won't have trouble finding Rails developers but not so much when it comes to Python.
Github is filled with probably more Ruby than Python.
Python is more popular, Ruby is more trendy and visible.
http://www.langpop.com/
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
http://www.langpop.com/
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
FreeBSD, FTW!!!