Feature-Rich FreeBSD 10 Alpha Released

An anonymous reader writes "The first alpha release of FreeBSD 10.0 is now available for download. FreeBSD 10 features include replacing GCC with LLVM/Clang, VPS support, an AMD Radeon KMS support, Raspberry Pi support, Bhyve for HVN virtualization, and ARM EABI support."

Comments

Hurrah?

[DavidClarkeHR]

Year of the BSD desktop.... FINALLY!

Re:Hurrah?

[tlambert]

Not just userland. Much of the OS X kernel is derived from FreeBSD and NetBSD, too.

Almost all of the BSD in the kernel is based on BSD 4.4-Lite2 and NetBSD; there are a couple of small sections, which ironically I wrote, that were pulled in from FreeBSD, like the BSD parts of the init code, and parts that generally everyone wrote, like chunks of the networking stack. I really wanted to change some of the VM APIs to be more like FreeBSD, i.e. in band errors in value returns should have been converted to value returned into variables passed by address with out of band error returns, but this would have required work on the part of the Intel guys prior to the Intel code integration.

The problem, though, is that Apple has slowly stopped developing the Unix parts.

This is BS.

They've literally deprecated fork, because they can't be bothered to make it work reliably with Core Framework.

No, that's a combination of several factors, some of them being Apple having poor representation on the UNIX steering committee. Specifically regarding the committee, there's no such thing as a pthread_atexec() and several other APIs which would be necessary in order to make fork() deterministically useful in already multithreaded programs.

The CoreFoundation factor is a combination of GCD, which starts and stops threads behind the programs back (and can't register exec handlers), and directory services, which for non-root processes starts another thread as a means of security partitioning to support everything DNS and network address related. It doesn't actually need to do this, and neither does GCD, but between that and the missing process lifecycle management functions in POSIX for threads, it's not supportable.

Basically, CoreFoundation is a piece of shit. It's now showing its initial lack of threads support in the design, and binary backward compatibility prevents it being redesigned. Catch-22.

The positive side of this is that people effectively have to use posix_spawn[p]() instead, which means they don't have to copy a massive fricking address space from one process to the other, which is expensive as hell in Mach, since they haven't adopted the red/black tree acceleration for ptov[] translations, mostly because there's too much code that relies on address aliases. In CS terms, the p:v has a cardinality of 1:N instead of 1:!, which breaks code relying on ptov(). There wasn't a lot of it, but there was absolutely no hope of getting rid of the aliases without the VM API changes I mentioned previously.

So boo fricking hoo: use LaunchServices like you were supposed to be doing when using CoreFoundation, and quit using fork() directly, and your problems will go away.

Neither are they tracking POSIX or BSD developments anymore, having stopped several years ago.

The only "tracking" of BSD kernel code that happened since 2003 that I'm aware of (but I left Apple in 2011) was in the networking code, and there was precious little of that, since Apple and BSD selected different concurrency models. BSDs is arguably more scalable, if you have unlimited memory to burn, other wise you want XNUs. You probably want XNUs anyway, particularly if you want to take cores on and offline out from under the CPU for power management or thermal budgetary reasons, and the scalability issues can be addressed.

OS X's POSIX support is a full release behind. They're compliant to the 2001 specification, but the latest is 2008, plus fixes. In a few years, their POSIX support will be about as useful as Windows', in terms of interoperability with modern FOSS.

That just asinine.

First off, the next jump to standards conformance, if any, will be unlikely to be 2008, since it's not going to be widely adopted by industry until IBM and Oracle can get their shit together, which takes more than 5 years, since it includes a migration strategy for mai

Re:Hurrah?

[tlambert]

The UNIX side of OS X has been just fine in the recent releases. The problems with OS X are:

1. It doesn't have a real package management system.

It's called "drag and drop"; properly written applications are self-contained in directories represented by the application icon. If you follow the Mac model, and don't try to install your files all over from hell to breakfast, there's no issue. This is why a lot of demo machines in stores now have epoxy in their USB ports (e.g. the ones at Fry's), since people were stealing already activated copies of Microsoft Office by plugging in their iPod shuffle or other thumb-drive and just dragging it over.

If you want to install all over from hell to breakfast, there's always http://www.macports.org/ or you can make a 5 line change to the FreeBSD ports management system to use "${MAKE}" instead of "make", and deal with two "echo" compatibility issues which are fixed by using "printf" instead, and almost all of the FreeBSD ports system "just works". I gave those patches back to FreeBSD (via Jordan Hubbard); not sure if they made them in.

Note that another benefit of the Mac model is that you can have different applications requiring different versions of libraries, and nobody cares except people already short on disk space. Duplicate block coalescing can fix that, but only works for ZFS, which is an add-on.

2. Long turnaround time for security patches. They should stop this insane "we have to wait until 10.x.y until we ship this patch even though it's ready." A proper package management system would certainly help there.

This is an issue for security problems in the kernel; otherwise, Apple ships regular security patches for all user space components; leave Software Update turned on, and it's automatic, and will pop up and bug you to install updates, since they usually mean an application or system restart (depending on what layer the installs happen).

For the kernel, this is really a management/resources/security-guys-do-not-push-hard-enough problem; the current development model for the Mac OS X kernel is "Scrum", which is good if you want to keep an organ bank of coders around to throw at the next iPhone/iPod Touch/iPad problem, and less good if you actually want to make substantive changes or progress in kernel technology, so it's mostly on managements back. I agree this is a problem.

TCP congestion control research in FreeBSD

[bcreane]

FreeBSD hosts interesting work with respect to TCP congestion control. An earlier version (I think FreeBSD 8.0) introduced modular congestion control algorithms, and this version introduces CAIA Delay-Gradient (CDG) congestion control algorithm. The check in is here: http://svnweb.freebsd.org/base?view=revision&revision=252504, and an interesting (if slightly esoteric) slide deck is here: http://www.ietf.org/proceedings/84/slides/slides-84-iccrg-2.pdf.

Re:The real problem with BSD

[Anonymous Coward]

Apparently you missed http://www.freebsd.org/handbook

In well written english, with screenshots and everything.

Re:The real problem with BSD

[Dahamma]

Everything you say is true. But are the Linux developers really all that different? There have been some epic flamewars on LKML and plenty of RTFM...

The fact is OS developers are generally extremely smart, "self-confident" (I'll try not to say "egotistical" or "arrogant"), and possibly somewhat socially awkward/blunt. The only reason you don't get that from Windows and OSX is that MS and Apple hide their kernel developers away from public debate :)

Re:Competition is always good

[dbIII]

It is with things like ZFS - the linux implementation (which I'm also using) is currently miles behind the freebsd version.

Re:The real problem with BSD

[Dahamma]

These people should not be answering questions from rank newbies.

Yes, and there are ways of saying that to someone that are not condescending, rude, or just plain assholish.

Though you know, some people in fact DO like helping others, even newbies (sometimes we call those "teachers", and sometimes they are just good people). But even if someone doesn't want to help, "please use XXX list for this question" is really not any harder to type than than "stupid question, stop posting here and RTFM".

Re:The real problem with BSD

[Osgeld]

and instead of politely pointing it out, you had to make yourself sound like a snotty condescending ass about it

grats for proving the op's point

Re:The real problem with BSD

[epyT-R]

computers are complex tools. The more operating systems try to hide that, the more dumb the users get.. it's a race to the bottom.

This antipathy towards learning curves is a big part of today's society (the idiocracy). Not only do people abhor learning, their superiors refuse to give them the time necessary to do it... Thus we end up with desktop operating systems that work like tablets. Everyone now thinks all computers should work like smartphones, no matter what they need the machine for. Complex procedures do not work like they do in star trek. Deal with it.

There are users like this with every os, not just linux.

you fuck off.

Re:security

[Anonymous Coward]

As much as I love freebsd I have stopped using it after their servers got 'served' with the use of 'legitimate' ssh keys. http://www.paritynews.com/2012/11/19/487/two-freebsd-project-servers-hacked/

Given that Freebsd never released a good audit report after that hack I can only be worried more.

Add to that, we now that we know the NSA had access to the certs from diginotar and might had done or paid for the diginotar hack I think one might as well use windows. I hate to say it, but the complete codebase from freebsd needs to be checked. Again and again. Preferable with the help from openbsd.

Maybe you should read over the report from freebsd.org: http://www.freebsd.org/news/2012-compromise.html

1) It was a single ssh-key that was leaked.
2) The accompanying user rights allowed access to two build server nodes which they took offline and they compared the data to a known good offline copy.
3) They pulled the 9.1-RELEASE packages they couldnt verify.
4) The compromised user only had access to the build system for binary packages. The BUILD system (and third party at that). NO access to the source repositories (except checking out, like you and me).
5) If you didn't use the 3rd party binary packages you weren't affected at all. (and who uses binary packages with freebsd anyway?)

I don't know how the infrastructure is organized in your company, but usually there is a user management on a server if you hand out ssh-keys and only a few if any are allowed to sudo su. IF there is sudo at all. That isn't a desktop box where every user added gets an entry in sudoers to su.

Re:Advantages / disadvantages vis-a-vis Linux?

[kthreadd]

Advantages:

* The OS and the applications are separate. This means that you can have up to date versions of your desktop and all applications on a stable core OS. On Debian you would either have to build things yourself or upgrade your entire system to testing or sid.
* A mature ZFS implementation. You can use ZFS-on-Linux or Btrfs for similar functionality on Debian, but it's often not considered to be as production ready as ZFS on FreeBSD. Also for license compatiblity issues ZFS-on-Linux will never ship as part of a GNU/Linux distribution and will have to be installed separately.

Disadvantages:

* Not as good hardware support. Usually works well on desktops and servers, but it can take some tweaking to get it to work well on modern laptops.
* Some software does not run on FreeBSD. Very uncommon for open source, but can be a problem if you're running non-free software. You can mitigate this by installing the Linux compatibility layer on FreeBSD.