Slashdot Mirror
FreeBSD Status Report for 2005 Q2
koinu writes "FreeBSD Status Report for the second quarter 2005 has been published by Scott Long. It gives a more precise description of what is being done on the 18 Summer Of Code projects." From the post: "The Google Summer of Code project has also generated quite a bit of
excitement. FreeBSD has been granted 18 funded mentorship spots, the
fourth most of all of participating organizations. Projects being
worked on range from UFS Journalling to porting the new BSDInstaller
to redesigning the venerable www.FreeBSD.org website."
No but Google did bring in some $90000 worth of support through their Summer of Code project.
Ewige Blumenkraft.
Did you not read it?
"The purpose of
quickly jumping from 5.x to 6.0 is to reduce the amount of transition
pain that most users and developers felt when switching from 4-STABLE
to 5.x. 6.0 will feature improved performance and stability over 5.x,
experimental PowerPC support, and many new WiFi/802.11 features. The
5.x series will continue for at least one more release this fall, and
will then be supported by the security team for at least 2 years after
that. We encourage everyone to give the 6.0-BETA snapshots a try and
help us make it ready for production. We hope to release FreeBSD 6.0
by the end of August."
Soft updates are an alternative to journaling, but they still require a fsck on an unclean unmount. Although this fsck can be done in the background (with snapshots) after the filesystem has been mounted and is otherwise available for normal use, the fsck still takes significant time and system load - neither of which are an issue with an unclean unmount of a journalled filesystem. I believe one of the primary motivations behind adding journaling to UFS is to remove this drawback relative to journaled filesystems.
There is softupdates, which orders things a bit. After a crash, there should be (knock on wood) only a few minor errors related to free space not being marked free.
There is sync, the traditional and fairly slow way. This generally provides unneeded determinism for directory operations. Normally we want as many pre-crash changes as possible, not just ones that can be made in perfect order. Some very unportable BSD software relys on sync behavior.
There is async, which plays fast and loose with everything. This works rather poorly on FreeBSD. It is likely that fsck will make a mess on boot, and illogically an async mount is slower than a softupdates mount. Linux has a nearly-true async, the default for ext2, that is very fast. (if an app explicitly requests a sync, the request is not ignored) The ext2 fsck is also extremely reliable, allowing for recovery of async filesystems that would be unheard of in the BSD world.
So that is:
- async
- sync
- soft updates
- full data journalling
- ordered data journalling
- metadata journalling
(and the patented obsolete delayed ordered writes from SysV, if I remember right)The really strange thing is that sometimes heavy-duty journalling can be fastest. This is often the case with mail servers which explicitly sync data to disk. A full-data journalling filesystem (as ext3 can be) may legitimately report completion as soon as the data hits the log, which is a nice big linear disk write. Other filesystems, though faster for normal use, will have to seek all over the disk before they can legitimately report completion.
Modern hardware screws all of this up horribly though. As the XFS developers discovered to their horror, power loss will corrupt data in memory or in transit to the disk before it stops the disk from operating. (yes, even when using appropriate fence or flush operations) Uh oh...
Wireless has worked with FreeBSD for a long time.
What hasn't worked was newer forms of wireless encryption, like WPA-PSK.
Common sense is not so common.
"I've been able to patch boxes running or 4.x for quite a while now, but jumping from 4 to 5, or in this case from 5 to 6 requires a complete reinstall."
It's very hard for me to believe that you've been running FreeBSD servers for years, and don't know that version to version upgrades can be done with minimal pain. Upgrades from one version of FreeBSD to another *do not* require complete reinstalls.
Yes, a 4.x to 5.x upgrade has the potential to be tricky, due to the major changes involved, but upgrading from 5.x to 6.x will not be a nearly as hairy.
Take a look at this email from one of the FreeBSD developers, in response to a question just like yours.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
Google did bring in some $90000 worth of support through their Summer of Code project.
Not to mention the remaining 1.91M they spent on other projects. FreeBSD just one of about 40 projects mentoring 400 students. The Nmap Security Scanner project is mentoring 10 of them, who have already produced great work! A list of their credentials and projects is available here. I'll give an update on their progress at my Defcon Presentation this Friday at 10AM.
Meanwhile, many of the other SoC mentors have posted details on the projects being worked on. For example,
- NetBSD
- Gaim
- Inksape
- MozDev
- WinLibre (with pics!).
Cheers,Fyodor @ Insecure.Org
I can't recall FreeBSD saying anything bad about shared libraries. Care to provide some proof?
FreeBSD did not disparage journalled file systems. They said soft updates gave most of the advantages without the cost, and may be faster. For some workloads soft updates are better, for some they are not, but until FreeBSD implemented them nobody knew.
FreeBSD was never against ELF. They just had no need - ELF solved some very real problems in the early versions of Linux, and because it was the standard when the linux developers went to fix those problems (back when linux was only a few years old) they went with ELF at the same time. FreeBSD did linking differently, and didn't have the problems early Linux did. The only reason FreeBSD now uses ELF is the GNU tools support ELF better. Otherwise the old FreeBSD a.out is just as good.
IDE disk drives are still bad. However they are cheap so everyone uses them. (the advantages of SCSI are rarely seen on home machines. High end servers still use SCSI for good reason)
I don't know where you got the idea that FreeBSD ever said anything against X.org, because they never did. The position is We don't care about what X server you run, but the X.org people seem like they might be more responsive to users, and that is a win, so we are going with X.org for all new versions. Because they are conservative about changes in general, they maintain XFree86 for old versions.
Very good comment on openVPN - likely the most flexible solution.
However, as for wpa with aes:
With 802.11 and WEP, data integrity is provided by a 32-bit integrity check value (ICV) that is appended to the 802.11 payload and encrypted with WEP. Although the ICV is encrypted, you can use cryptanalysis to change bits in the encrypted payload and update the encrypted ICV without being detected by the receiver.
With WPA, a method known as Michael specifies a new algorithm that calculates an 8-byte message integrity code (MIC) using the calculation facilities available on existing wireless devices. The MIC is placed between the data portion of the IEEE 802.11 frame and the 4-byte ICV. The MIC field is encrypted together with the frame data and the ICV.
Michael also helps provide replay protection. A new frame counter in the IEEE 802.11 frame helps prevent replay attacks.
AES support
WPA defines the use of Advanced Encryption Standard (AES) as an additional replacement for WEP encryption. Because you may not be able to add AES support through a firmware update to existing wireless equipment, support for AES is optional and is dependant on vendor driver support.
Google for "wpa aes" to find 344,000 other articles about it.