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."

Re:Why is NTFS read only.

[Anonymous Coward]

If it's so easy, and you seem to care, can we expect your diff on misc@ in the next few days?

Re:Why is NTFS read only.

[hedwards]

Contamination isn't normally an issue for kernel code, they can always cram it in its own corner of the code and not include it in binaries by default.

Without being involved with the discussions its hard to say, but I've personally found Linux filesystem code to be less than reliable. But there's also the issue of that it would have to pass their auditing to be included in the base install, there's a reason why they have so few base exploirts.

Re:Why is NTFS read only.

[JamesP]

They can post, but TDR will never accept it. NEVER!!11 (insert maniac laughter)

OpenBSD is knows for things like throwing away wireless drivers, for example.

Re:missing some key features...

[rubycodez]

why, they're not necessary. The flags for starting a daemon are in /etc/rc.conf and /etc/rc.conf.local, and the pid of running daemons are in /var/run or use ps ea for them. Simple and clean with no cruft is why I like OpenBSD for applicances and routers so much.

Re:Why is NTFS read only.

[fuzzyfuzzyfungus]

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.