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."

Re:The real problem with BSD

By Dahamma

2013-Sep-15 00:10

• Score: 4, Insightful
• Thread

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

By dbIII

2013-Sep-15 01:06

• Score: 4, Informative
• Thread

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

By epyT-R

2013-Sep-15 02:40

• Score: 4, Insightful
• Thread

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.


By Anonymous Coward

2013-Sep-15 02:43

• Score: 4, Informative
• Thread

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.


By tlambert

2013-Sep-15 04:18

• Score: 5, Insightful
• Thread

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

Show more