Slashdot Mirror
FreeBSD 4.0 Code Freeze
FreeBSD has now entered code freeze for the up and coming 4.0
release. In the words of Jordan Hubbard, the release engineer; The code freeze will last for 15 days, during which time the 4.0
snapshot server (current.freebsd.org) will be cranking out its daily
snapshots (and, in the last half of the release cycle, ISO images as
well). 4.0 is the first release from the latest FreeBSD -current development branch. Work also continues on the 3.x -stable branch.
-Dom
A few comments:
If by "user-friendly" you mean "lots of sometimes-confusing options" then, yes, the GNU tools tend to have more features, and you can arrange your command-line arguments twelve different ways from Sunday. That's not necessarily a good thing, though I admit it's a matter of personal taste. Taking your example:there is no direct BSD equivalent, but I'd tend to use something like:
in any case. cp has entirely too many options as it is. It's easier for me to remember the tar pipeline than the two dozen options that GNU cp supports. It's the Unix way--combining tools into pipelines and sequences like LEGO blocks--while the GNU way has tended more towards the all-in-one approach. So when you say "there's no equivalent for *BSD" you really meant "there's no equivalent command." It's not impossible or even necessarily harder to do in BSD-land (though I admit it's more typing, and less intuitive to folks used to DOS-land).
You also say that:
I couldn't disagree more! Doing a "make config" (or its curses or X11 equivalent) in Linux is a tremendous leap of faith compared to configuring a BSD kernel. There are over a hundred questions to be answered, and a wrong answer to any one of them can torpedo your chances at a working kernel. You're no more vulnerable editing a BSD config file, and in fact if you have a listing of the LINT config you usually know just what you need to know to enable/disable any given option or driver. I've experienced the Bad Old Days (having edited SunOS config files more times than I'd like to admit) and I have to say that BSD configuration has improved a lot, both in terms of documentation and of things you can leave for the kernel to figure out itself.
You also mention:
I agree (as would a fair amount of the BSD community) that Linux is getting an edge in SMP. The fact is that this is often of limited importance for well-designed server installations. It's actually an advantage (if you can architect it) to distribute load over n entirely separate hardware entities than some n -CPU entity. That way, a failure won't take out n units of capacity, just 1 . Harder to do? Sure, in some ways it is. A bunch of processors sharing memory allow solutions that isolated processors connected only via an LAN cannot. But this hasn't been that much of a limitation for my employer, Yahoo!. Your mileage, of course, might vary.
I've run both Linux and FreeBSD for several years, now, both at work and at home. They both have their strengths. As a "Fundamentalist" Unix person, BSD seems a bit more like "home" to me. But I'm typing this into my home Linux box (a foot from my home FreeBSD box), and I have to admit that there is greater breadth and depth in the current Linux scene--in general, though not necessarily in specific areas. And sometimes the Linux folks seem to be adding legs to the [painted] snake (to use a Zen aphorism). But I see nothing but "synergy" (what a polluted word at this point, but I know of none better) between BSD and Linux, or even between the GNU and Unix (non-commercial and commercial) camps. (And you though the "Gnu's Not Unix" acronym was merely cute.) I'll likely be using both of these great systems for a long time--until something better comes along. (Not likely :-).
didn't eat file systems (unlike 2.2.5-2.2.14 Kernels)
:)
:P
:)
Exactly _one_ of those versions had known fs integrity problems -- 2.2.8. You'll find that 2.2.9 was released about one day later.
it didn't leave the FS in a shitty state that required manual intervention like ALMOST EVERY LINUX CRASH I've ever had/seen.
Really? The only Linux crash I've had that required manual intervention to reboot I managed to trace back to a hardware problem.
Thats pretty crummy, especially when it couldn't even use all of the 1GB of memory in the box,
Current 2.3 releases support up to 64M on Intel hardware.
BTW, FreeBSD 4.0 has support for USB Ethernet adaptors, like those on the Sony VAIO's. Linux barely supports USB, not to mention anything other than a Keyboard and Mouse. Where's that desktop now?
Right. Current Linux 2.3 releases support USB mice, keyboards, joysticks, cameras, scanners, printers, serial ports, audio, and more. But, I guess, without those USB ethernet adapters, Linux is toast on the desktop.
Looking at the supported hardware list for FreeBSD 4.0, I don't see any other USB peripherals supported other than your precious ethernet adaptors. Where's the beef?
You know, you're exactly the kind of BSD user that the previous poster was complaining about. A lot of 'FreeBSD is more stable/faster for me', a bunch of demonstrably _wrong_ facts, and not one iota of solid proof to back up your claims.
Is a little bit of integrity too much to ask?
FreeBSD does not have HOWTOs, we have documentation. :-)
:-)
Anyway, I do not know if it would be interesting for you, in particular to try FreeBSD. Some people like it better, some don't. It's a matter of taste.
For help, check out the official website for general information, the handbook for general documentation, the FAQ for frequently asked questions (including some installation problems) and the FreeBSD Diary for the most recommended beginner's site.
BTW, FreeBSD installation is generally known to be easy and painless. It can be done through the net by downloading just two floppy disk images, and there are mirror sites all over the world, and this list of mirror sites is shown to you during the installation.
(8-DCS)
Many, many things are new with 4.0.
Dillion reworked a lot of the VM subsystem.
Much more USB drivers, including a dozen or so USB ethernet adapters.
Uh, lots of stuff has been being worked on.
As for two week freeze period, it isn't too short
as basically before the freeze everything was going well (minus the small softupdates fiasco)
as the only stuff in -CURRENT is (supposed to be) tested by the programmer.
I'm using my time to make what ever doesn't compile with -Wall -Werror go by without a hitch.
And I'm not sure where you got that 15 day quote. I talked to Jordan about 15 minutes ago and he said he'll play it by ear-- but -RELEASE should come at the end of this month.
-bugg
FreeBSD does things a bit differently than Linux. All code is in a CVS server. Every day (more or less) many developers bring their code up-to-date (with "cvsup" or equivalent) and do a "make world," perhaps after reviewing that day's changes first (which are posted automatically to a mailing list). Then they run their favorite tests and/or applications. So you can say that the FreeBSD system (not just the kernel--everything needed to run a FreeBSD system) is under continuous integration and testing. Everything is known to more-or-less work and play together before the freeze. The 15-day shakedown is thus a time to focus on finding issues that somehow got missed during the continuous develop/integrate/test process.
This is different from Linux; in some ways it's slower and more restrictive, but I rather like it. Although 4.0 has a lot of improvements over the 3.x series, most of them are evolutionary, especially compared to some of the wholesale reworkings of kernel mechanisms between major Linux releases (1.2, 2.0, 2.2, 2.4...). This, combined with the FreeBSD development methodology, mean that instead of a mad scramble to get everything integrated for a final release, it's more a matter of dotting i's and crossing t's until the system passes muster with the core team and the CVS tree is labeled RELEASE.
As to just what is new and/or different in 4.0, there are folks here who know much better than I do...
I'm wondering if trying out FreeBSD would be at all interesting? How much help is there with
;-).
;-), but they're arguably less-advanced. The FreeBSD package system doesn't support versioning of packages (eg, it can distinguish openssh-1.20 from openssh-1.21, but it can't distinguish openssh-1.21-10 from openssh-1.21-11 like debs / rpms do, which I find to be a pain when I'm upgrading my installed ports)
/usr/ports/editors/vim5 ; sudo make install
;-) for most operations, though not for things like deleting large directories; of course, *BSD advocates will tell you it's a safer filesystem than ext2, so your mileage may vary.
;-). There's no menuconfig / xconfig / config like in Linux. Honestly, though, that's really not something to pick an OS on one way or the other ;-)
installation problems? HOWTOs?
You'd probably find it interesting if you're the kind of person who installs different Linux distributions from time to time out of interest
My basic comparison:
* Installation feels about like Slackware in terms of package selection and such
* Base install is very small, as very little comes with the OS--everything is in ports instead.
* FreeBSD has packages like real Linux distributions (and no, Slackware people, tgz is not a package
* The ports system is pretty cool. It's somewhere between Red Hat and Debian in terms of size (at least for FreeBSD; the other two *BSD ports trees are somewhat smaller), and a little more slow about updating (and, oddly enough, a little *more* buggy, contrary to expectation) than the Debian system. At any rate, it's an archive of scripts + patches necessary to integrate all the standard software into your system. Want vim?
$ cd
and it will download the source, apply any necessary patches, compile the package, and install the package (which you can remove later either by make deinstall or by pkg_del vim5)
* Documentation is quite good and thorough, though a little out-of-date (it's basically for 2.x, though is being rapidly revised to reflect the 3.x that most people are now running). It tends to be a little more basic than Linux HOWTOs in terms of what it covers, but it's a lot more thorough about covering essentials than the HOWTOs are.
* Usage-wise, FreeBSD is mostly BSDish. That means no SysV init that you're probably used to (the vast majority of Linuxen use SysV init for various reasons) and similar differences like that which you'll have to pick up as you go with the help of the FreeBSD Handbook alluded to above.
* The BSD toolset tends to be a little less user-friendly than the equivalent tools from Gnu. Eg, with Gnu tools, you can decide after the fact to add the switches, and they work:
rm foo -rf
rm -rf foo
are both acceptable with Gnu rm, but not with *BSD rm. Similarly, the Gnu toolsets tend to support options that the *BSD ones don't:
cp -Rv
on Gnu will show you what it's copying. There's no equivalent for *BSD.
* Some technical differences. In the Linux world, the "standard" Microsoft scheme of primary partitions + logical partitions within an extended partition is used. For the *BSDs, you make one partition, and then set up slices within it (conceptially, this is like logical partitions w/in an extended partition).
* Performance differences--FreeBSD SMP is noticeably slower than under Linux on the same hardware. FreeBSD is Intel-only (with Alpha port progressing and Sparc planned) whereas Linux runs just about anywhere, more like NetBSD. FreeBSD's net stack is rumored to be faster / more correct than Linux's, though you'll never find anyone to substantiate that one way or the other (beyond some of the Linux developers pointing out pathological cases where standards conflict and they argue Linux does the Right Thing and FreeBSD doesn't). UFS, the FreeBSD file system, is slower than ext2 (even with soft-updates--basically "go faster" stripes you can add in when you recompile your kernel
* Kernel compilation is more like the Bad Old Days under commercial Unixes. You have a flat text file full of all the options you want in your kernel, and if the ones you need aren't there, you try to steal them from a different one and add them in
I'm tired, so I'll quit now. Others, feel free to add in other differences.