Feature-Rich FreeBSD 10 Alpha Released 143
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 (Score:3, Informative)
Apparently you missed http://www.freebsd.org/handbook
In well written english, with screenshots and everything.
Re:Competition is always good (Score:5, Informative)
Re:security (Score:5, Informative)
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/ [paritynews.com]
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:Hurrah? (Score:5, Informative)
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? (Score:2, Informative)
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.
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.
Re:Advantages / disadvantages vis-a-vis Linux? (Score:4, Informative)
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.