Slashdot Mirror
FreeBSD 7.0 Release Now Available
cperciva writes "The first release from the new 7-STABLE branch of FreeBSD development, has been released. FreeBSD 7.0 brings with it many new features including support for ZFS, journaled filesystems, and SCTP, as well as dramatic improvements in performance and SMP scalability. In addition to being available from many FTP sites, ISO images can be downloaded via the BitTorrent tracker, or for users of earlier FreeBSD releases, FreeBSD Update can be used to perform a binary upgrade."
You don't need to set the disk geometry unless you have weird-ass old disk hardware. Just accept the defaults.
The summary says it has ZFS support but the website says experimental ZFS support. That seems like a pretty important distiction.
It's quite good. Where I work, we've been using the release candidates to store upwards of 15 TB of data, spread over about 50 hard drives. We haven't had any problems, and the performance has been fantastic.
Solaris still offers better support, but the ZFS support offered by FreeBSD is production quality.
Slated for 7.1 is support for booting GPT partitioned disks. This will make the whole partitioning thing even easier, since it will make BSD labels and the MBR go away entirely, and partitioning will be done entirely using LBA addressing.
There is a good interview with many key FreeBSD contributers about new technologies and improvements in 7.0. It is quite technical.
http://www.onlamp.com/pub/a/bsd/2008/02/26/whats-new-in-freebsd-70.html?page=1
*I love how STABLE just sticks out, like BSD wasn't stable before. Ha!*
"7-STABLE" is FreeBSD-speak for "this implements the FreeBSD 7 API/ABI, and any program you write or compile for an earlier release will work just fine on a later release". In other words, the Application Programming/Binary Interfaces won't change in incompatible ways.
This is in contrast to Linux, where updating to a new kernel (belonging to the same "stable" kernel branch, or even applying security patches) can make programs break until you recompile them.
Tarsnap: Online backups for the truly paranoid
I've never needed to know any of those things to install FreeBSD. We run a number of FreeBSD virtual machines and physical servers. I installed them all myself. The most complicated part was entering network information, since all of these systems had static IPs and weren't using DHCP. Unless you're doing something out of the ordinary, you can just use all the defaults and have a fully working system in 15-20 minutes on an average machine.
I've been using FreeBSD since version 2.2.7. I've been using Linux and other OSs even longer. Operating systems that have been around as long as these weren't just created from the start to be a breeze to install. Linux used to require a lot more manual configuration than it does now... just because something like Ubuntu makes it easy doesn't mean it always was. Linux has progressed in this area, and so has FreeBSD, and so have most other mature operating systems.
Also, FreeBSD is not targeted at the same audience as something like Ubuntu. A better comparison would be PC-BSD and Ubuntu, as they are targeted at desktop users. I guess maybe FreeBSD could be compared to the server or alternate editions of Ubuntu, in which case the install process (using text screens) is fairly similar.
perl -e "eval pack(q{H*},join q{},qw{70 72696e74207061636b28717b482a7d2c717b343 637323635363534323533343430617d293b})"
Press "A" for auto partitioning and then "A" in the disk layout section for auto-defaults.
As it has been since at least FreeBSD 4.0.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
I haven't run FreeBSD since 6.0, but the problem with Dells, IIRC, is that the AT controller acts like there's a keyboard there even if there isn't one.
I had no problem using the clearly labeled "boot with USB keyboard" menu option.
It's a moot point -- with the at mux that came in I believe halfway through the 6-series, you can have as many keyboards as you feel like.
Please look at PC-BSD or DesktopBSD; they would be the equivalent to Ubuntu.
http://www.pcbsd.org/
http://www.desktopbsd.net/
Disk Geometry trolling isn't funny or have you confused this with partitioning. So, are you trolling or are you stating that you don't like to partition drives. If it is partitioning then you may want to check out the above links; if you're trolling, then continue with what you're doing
GREAT article - it is interesting for a non-programmer to read this type of technical detail, presented in an understandable way. For me, right at the edge of my theoretical-only knowledge. A detailed summary, I guess. (oxymoron)
Similar article on NetBSD: Waving the flag: NetBSD developers speak about version 4.0 (1/30/2008)
Linux focused links:
Current discussion:
LWN: Kernel
KernelTrap
KernelNewbies: Summary of Linux Changes
---
The Wonderful World of Linux series are excellent history - in-depth for outsiders:
WWOL 2.2
WWOL 2.4
WWOL 2.6
---
Towards Linux 2.6 - A look into the workings of the next new kernel(2003)
Kernel Comparison: Linux (2.6.22) versus Windows (Vista)(2007)
"Does ZFS really require that much memory?"
No, but if it is available it will certainly use it. The upside of ZFS using more memory is that disk IO will be lower so better overall performance.
You underestimate my capacity for wrongness.
Softupdates don't solve the important unclean shutdown fsck problem very well. Background fsck is a nightmare for any production system with non-trivial amount of spinning rust.How's that? I mean, I'd rather not have to fsck my terabyte RAIDs, but if I have to, at least the system can be running live and undegraded while the loose ends get cleaned up.
Wrong. Half the writes as compared to the naive gjournal journalling. Real modern journalling filesystems usually have the option to journal just metadata. What's more, journalling is far more flexible than softupdates. You can journal to a small battery backed RAM device for example.If you're just journaling metadata, then you're not getting the full benefit of journaling (and definitely not anything more than softupdates offers, as it's basically an in-memory ordered journal of metadata transactions to be committed). As far as the battery-backed RAM: that's like saying cats are better than dogs because you can give them medicine if they get ringworm. BTW, with FreeBSD's GEOM system, you could journal to an encrypted RAID on a remote host if you wanted to. You might have already known that; others might not.
Wrong. There has to be some filesystem support work done.Wrong. gjournal is a generic journaling provider. You can use it to wrap any other GEOM component. From it's own man page:
Pretty neat, huh? You can wrap it around your RAID to make it crashproof. If you think background fscks are bad, then you've probably never watched a few terabytes of mirror resync itself. Anyway, what you misunderstood is that filesystems have to be altered to interact meaningfully with the underlying journal. UFS has been so modified. That doesn't mean that other filesystems won't work on top of it (which would be silly because a gjournal looks just like any other block device), but that they're not optimized for it.
Dewey, what part of this looks like authorities should be involved?
No, you read that right. The reason is mainly that FreeBSD users have been enjoying something called "softupdates" for the last decade or so, which is sort of like an in-memory journaling. Rather than writing metadata directly to disk, it's queued in memory, grouped into an efficient order, then transactionally committed to the underlying drive. The disk is never in an inconsistent state, even without a journal to fall back on. If the system crashes, a special fsck that can run while a filesystem is mounted read-write comes along and deallocates any space that's no longer used but hasn't yet been marked as empty.
Because of that, there hasn't been much need or real drive to get journaling into FreeBSD. The solution they're going with is actually nicely abstracted, in that you configure a journal for a whole device through GEOM (which is kind of like a Lego set for building drive setups). Although you'd probably never want this, you could theoretically have two "drives" that reside on remote machines (via ggate) bound together with RAID1 (via gmirror), encrypted (via geli), and with a local journal (via gjournal).
Dewey, what part of this looks like authorities should be involved?
Seriously, jump! I switched from Debian (2.something, I think) to FreeBSD 4.5 *years* ago. I haven't been happier.
:-)
I'm still running FreeBSD 6.3 on my server, and I will upgrade to 7 soon, but I found PC-BSD to be the better desktop system (DesktopBSD had strange quirks, and wasn't as polished).
PC-BSD uses the "stable" FreeBSD as it's base, so although it's currently FreeBSD 6.3 based, that'll no doubt change to 7.0 soon. PC-BSD also uses KDE as it's desktop environment, so you'll have no trouble with your apps.
Good luck!