Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A few corrections:

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.



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?

Is there any discussion about them we can read?


I think they are to support lightweight virtualisation like that used by Docker.io. This allows multiple processes to act as though they own a particular filesystem, which in fact in shared.


To me — not ever having tried them yet — it looks like they might be used to provide some of the same sorts of file system elegance as Plan 9 name spaces.


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.


Linux has namespaces which seem a little bit similar to variable symlinks (in that both allow different processes on one system to see different filesystem contents).


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: