FreeBSD 10′s New Technologies and Features
freebsdnews.net
freebsdnews.net
LLVM/CLANG: 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.
Tickless kernel: There's a spurious reference to "atomic close-on-exec" here.
PF: PF itself was ported from OpenBSD, while the SMP improvements were developed in FreeBSD.
Netmap: 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.
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?
Is there any discussion about them we can read?
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.
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 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.
for source code install; ports
pkg_add and pkg_delete are becoming obsolete by pkgng
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.
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.
For one example, take networking tasks:
Task / BSD / Linux
set ip / ifconfig / ifconfig or now "ip" which is 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
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.
Freebsd 9.1 RELEASE: 260k /sbin/ifconfig
My Arch box: 76K /usr/bin/ifconfig
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.
But use what you like. Just don't pretend that it's anything other than taste.
If you're calling my tastes simple then guilty as charged.
> git pull
> git push
> git clone
or would you prefer a binary for each command:
> git_pull
> git_clone
> git_push
now, what really looks old school to you?
What you're contorting is more akin to: ifconfig_wireless ifconfig_vlan ifconfig_foo
Bit of a reach there.
Very true.
> 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 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?
What exactly are you willing to bet?
> and that's not enough state.
It's enough.
> If you swap two identical cards between PCIe slots
It's probed by slot so in the case you present no config would generally be needed unless you have something dependant on layer 2 in the setup.
> If you pull em1 and add a new card in its place does it come up as em1 (incorrect)
Yes it does and actually that is correct. I don't want to have to muck with configs simply because I swapped a nic. If you like doing it that way have at it.
> 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?
Depends on the setup, you can have it pretty much do anything but by default it would work if you swapped it out with something that used the same driver.
> I admit I'm chuckling a little about the idea of udev not being "needed".
As someone who has ripped udev out of a distribution and replaced it with something easier(auto provisioning) for a specific large SaaS stack, I can assure you udev is not needed.
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..
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.
Although many things don't work on debian/kfreebsd, and searching for help is tricky, do I go the debian way or the freebsd way, it's always updated with few problems.
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".
1. feels closer to "old fashioned non-Canonical'ed UNIX" which I was brought up on.
2. Way less politics due to license.
3. Less crazy forking and wheel reinventing (basically everything Ubuntu isn't).
4. It has orders of magnitude better documentation
5. pkgng is actually really nice
6. separation of core OS vs ports/packages so easy to stage updates compared to catch all Linux distros.
7. pf is miles better than iptables
8. ZFS.
9. I have a Sun Ultra 30 sitting in my cupboard which Linux doens't like.
10. Has valgrind that works properly unlike the other BSD's.
That's about it but it's enough.
My use cases are: personal use, professional use (devops), professional use (production).
So much goodness!
See http://lists.debian.org/debian-bsd/2013/07/msg00060.html and http://asdfasdf.debian.net/~salinger/eglibc.fbtl/
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).
That will pull binary packages from ports builds on another machine and install and configure them.
I admit I had some level of apt-envy back when I was using portupgrade. pkgng has nicely eliminated that.
For installing:
pushd /usr/ports/*/$PACKAGE ; sudo make install clean && popd
sudo portsnap fetch update ; sudo portmaster -ad
A quick read - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/po...
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).
(cd /usr/ports/*/$PACKAGE ; sudo make install clean)
echo BATCH=1 >>/etc/make.conf
make config-recursive && make install clean
make -DBATCH install clean
-c
--config
Run "make config-conditional" before everything for all tasks.
-C
--force-config
Run "make config" before everything for all tasks.
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.
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 don't know how good the laptop hardware support is - my impression is more people use it on the server. My wifi works fine, but you should probably check yours is supported.
But on a server or even a desktop computer, it's really great
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.
It's more a "can't" than a "won't". They can't incorporate GPL code into the BSD kernel without violating the GPL.
LGPL-licensed code might be something they could port as a pluggable driver, though don't quote me on the details there.
(The CDDL is decidedly not permissive, of course, but its a far cry from being more restrictive than the GPL.)
[1] https://en.wikipedia.org/wiki/BSD_licenses#2-clause_license_...
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.
Am I missing something about the BSD kernel licensing social dynamic?
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 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.
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.)
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.
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.
One of the good reasons to like BSD´s is because of its licence, not the opposite
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.
Some thoughts:
* 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.
You know, you don't actually have to use pulseaudio on Linux. Both Alsa and OSSv4 work fine.
Honest question: why?
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).
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.
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.
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.
- Wifi worked out of the box.
- The people from #freebsd chan on irc were very helpful
- The handbook is very useful
The problems that I couldn't fix:
- Somehow I can't go back to terminal if I start x environment, afaik this is a problem of Intel HD Graphic cards (onboard on my notebook).
- No acpi support to adjust the brightness level, I have to rely on an app but it isn't the same.
- Touchpad support.. In ubuntu it works out of the box, two-finger scrolling and all, in freebsd I have to struggle a little with xorg and the end result is a little worse than ubuntu.
- I can't suspend my computer. It never wakes up :(
I still have to configure a lot of things (keyboard shortcuts, install better fonts, network manager).
It's not that I jumped from ubuntu to freeBSD, I've used archlinux for a few years before I got tired of it breaking my apps with the updates :P
I regret installing it on my notebook before trying it on my desktop or on a virtual machine.
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).
Other: 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.
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.
The code is actually nicer to read than the Linux counterpart and it seems trivial to implement a new "random_adaptor" that would xor the output of ivy (rdrand) with yarrow (the software one).
[1] http://fxr.watson.org/fxr/source/dev/random/ivy.c [2] http://fxr.watson.org/fxr/source/dev/random/probe.c
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
also projects like netmap are sweet..
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.
Theodore Tso - the author of Linux /dev/random thinks that using it is a bad idea https://plus.google.com/117091380454742934025/posts/SDcoemc9...
FreeBSD's new security framework -- Capsicum -- has been backed by Google: http://www.cl.cam.ac.uk/research/security/capsicum/
Yes you are.
> I said "decent", this implies at least "usable".
Agreed.
> It'd be nice to get that done by the time it hits stable, but I wouldn't hold my breath.
pkgng has been usable for over a year. Read the page I linked too.
Pkgng itself seems like it's working, but bootstrapped fresh on a FreeBSD 9.1 it provided a non-existing repo:
[root@freebsd91 ~]# cat /usr/local/etc/pkg.conf packagesite: http://pkgbeta.FreeBSD.org/freebsd:9:x86:64/latest
And that URL is actually a 404 page.
Additionally the existing binary repos (the one pkg_add uses) cannot be used with pkgng.
So essentially - unless you want to start building packages and maintaining repos - pkgng is at this moment _useless_.
I do wonder if they'll manage to come up with decent[1] repos in time for the final release.
[1] - 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.
Yes, you are.
> 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.
> [1] - 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.