Slashdot Mirror
OpenBSD 4.9 Released
An anonymous reader writes "The release of OpenBSD 4.9 has been announced. New highlights included since 4.8: enabled NTFS by default (read-only), the vmt(4) driver by default for VMWare tools, SMP kernels can now boot on machines with up to 64 cores, support for AES-NI instructions found in recent Intel processors, improvements in suspend and resume, OpenSSH 5.8, MySQL 5.1.54, LibreOffice 3.3.0.4, and bug fixes."
Also in BSD news, an anonymous reader writes "DragonFly BSD 2.10 has been released! The latest release brings data deduplication (online and at garbage-collection time) to the HAMMER file system. Capping off years of work, the MP lock is no longer the main point of contention in multiprocessor systems. It also brings a new version of the pf packet filter, support for 63 CPUs and 512 GB of RAM and switches the system compiler to gcc 4.4."
The specifications for NTFS are completely closed. If it's what Windows produces when told to format a volume as NTFS, it is NTFS. There are reverse-engineered attempts(NTFS-3G being the most practical, if rather slow); but they aren't entirely to the point where you'd want to trust vital data to them.
In the specific case of OpenBSD, I suspect that the read-only support is because the OpenBSD team has very low tolerance for what they see as crap. If they can't support something the way that they want to, they can and will just toss it(see the Adaptec RAID driver case, or some wireless chipsets). They don't do binaries, they don't do NDAs, they don't do blobs. They also don't like software they consider to be of inadequate quality. Thus, since the state of full NTFS support is a bit dodgy, it is entirely in character for them to drop it.
More broadly, NTFS read/write isn't really something that there is a strong incentive in the OSS world to polish to a high sheen. NTFS-3G is pretty much good enough for dual booters and rescue disks. NTFS doesn't have any points of superiority strong enough that building top-notch reverse-engineered support would be competitive with spending the same effort implementing a non-secret design. Also, for the sorts of purposes that pay the bills for a lot of Linux development, NTFS support is largely irrelevant. You don't dual-boot servers, and any halfway serious network setup is going to either use SMB/NFS(which makes the local filesystem irrelevant to all other hosts), or some filesystem with concurrent access support or other esoteric features that isn't NTFS.
NTFS R/W is really just a convenience feature for sneakernet and dual-boot scenarios. Neither of those really pay for enough development to get a fully baked reverse engineering of a (quite complex) filesystem.