Forgot your password?
typodupeerror
Operating Systems Security Unix Technology BSD

OpenBSD 4.9 Released 137

Posted by timothy
from the release-the-kraken dept.
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."
This discussion has been archived. No new comments can be posted.

OpenBSD 4.9 Released

Comments Filter:
  • by jack2000 (1178961) on Sunday May 01, 2011 @06:05PM (#35993294)
    Why is NTFS always read only. It shouldn't be so hard to make a proper file system driver what the hell?
    • Re: (Score:2, Insightful)

      by 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: (Score:3, Insightful)

        by JamesP (688957)

        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.

        • by Anonymous Coward

          Throwing out closed source binary blobs you mean. Yes.

        • Where can I buy a 63-core CPU?

        • by the_B0fh (208483) on Monday May 02, 2011 @12:05AM (#35995626) Homepage

          eh? The last wireless fiasco I remembered was one of the linux wireless guys stealing openbsd's reversed engineered code, and re-releasing it as their own. I guess you can say they threw away encumbered code as they reverse engineered and re-wrote it.

          • by SlashV (1069110)
            That wouldn't have been a problem, since that is what BSD'ed code is for. The other way around (bsd ppl 'stealing' linux gpl'ed code) is a problem, so my guess is that was what happened and that is also the way I remember it.
            • by tlhIngan (30335)

              That wouldn't have been a problem, since that is what BSD'ed code is for. The other way around (bsd ppl 'stealing' linux gpl'ed code) is a problem, so my guess is that was what happened and that is also the way I remember it.

              No, what happened was the Linux guys took the BSD'd code (not a problem - the BSD was designed for this), then locked it up with the GPL (they even had the gall to replace the BSD license with the GPL in the header files).

              The end result is because of this, all changes to the Linux drive

            • by the_B0fh (208483)

              *WRONG* on so many fronts. You were provided a URL below, so you can read it. But. And here is the important part. *YOU CANNOT TAKE SOMEONE ELSE'S CODE AND RE-LICENSE IT AS YOUR OWN. YOU DO NOT HAVE THAT RIGHT.

              *YOUR RIGHT* is to USE the code under a BSD, GPL or another license, as licensed to you by the copyright owner.

    • by Phibz (254992) on Sunday May 01, 2011 @06:13PM (#35993336)

      You do realize that NTFS is completely closed source right? All the work on it has been done through reverse engineering.

      • by DarkOx (621550) on Sunday May 01, 2011 @06:25PM (#35993424) Journal

        Add to that a few other fun things

        1.Multiple versions of NTFS with subtle changes
        2.Its a complex file system with lots of features, some of which are not even used by windows but you still have to take care of the on disk data correctly.
        3.The security scheme does not cleanly map onto UNIX style rules even with ACL support and such.

        NTFS is by no means avant guard but its by any means simple and without documentation figuring out its internals completely and correctly is a BIG job. Now why they can't gleen allot of that from the Linux source I don't know. I know they can't use the Linux source because of the GPL being incompatible with BSD maybe there is a contamination concern.

        • by hedwards (940851) on Sunday May 01, 2011 @06:33PM (#35993466)

          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.

        • by Hognoxious (631665) on Sunday May 01, 2011 @06:49PM (#35993570) Homepage Journal

          NTFS is by no means avant guard

          Just like your knowledge of French, it would seem.

        • by mlts (1038732) * on Sunday May 01, 2011 @07:21PM (#35993746)

          Those are important items, especially #1. There are a lot more which make life hell for someone trying to get NTFS to work fully as a supported filesystem for a UNIX based OS. A few more:

          4: Alternate data streams. It is common for malware to add an ADS onto a file, a directory, a junction point, or even the C: drive object itself. Without a dedicated utility that snorts out these, they are essentially invisible.

          5: Like #1 above, NTFS changes in undocumented [1] ways. For example, EFS changed to add different encryption algorithms between Windows XP and Windows XP Service Pack 3. So, not knowing that may bring someone a world of hurt.

          6: Similar to #3, NTFS's ACLs are hard to reimplement in the UNIX world. U/G/O permissions can be mapped (Cygwin does this).

          7: For a filesystem to be usable as a production one, it needs a filesystem checking utility that can go through the whole filesystem and check/repair integrity on every part of it, be it mostly unimplemented/unused items (transactional-NTFS), features off the filesystem (NTFS compressed files, EFS), and many other items.. Yes, there are ways to run Windows's chkdsk.exe utility, but that is a hack at best.

          One of the biggest problems with operating systems today is that there are no compatible filesystems beyond FAT and FAT32. Perhaps UFS. Either one filesystem has too much patent encumbrance to be used, or its license.

          I wonder how easy life would be if we had a standard filesystem that could replace the LVM (similar to ZFS), offer modern features (deduplication, encryption, 64-bit checksumming [2], encryption, compression (various levels), snapshotting [3]. On an LVM level, it would be nice to have mountable disk images similar to OS X's sparse bundles. If something changes on the encrypted drive, only a few bands change, as opposed to having to back up the whole file.

          Life would be easier if every OS out there had a common filesystem with modern features. A good example about how useful this would be would be antivirus scanning. Unpresent a LUN from a Windows server, scan it on a Solaris box for malware, then re-present it, for example.

          [1]: Undocumented unless you are elite enough to have the MS source code handed to you, all work on the filesystem is all reverse engineering.

          [2]: Backup programs would have it easy and not rely on dates or archive bits... just look for files where the checksum has changed and back those up just like the -c option in rsync.

          • I briefly used Kaspersky anti-virus, and now lots of my files have :KAVICHS: or something like that tacked onto them as alternate data streams. When I copy those files to devices that don't support them (e.g. memory sticks using FATxx), Windows has to pop up dialog boxes to warn me that it'll be unable to copy the extra baggage. [Insert snarky comments here...]

      • if ReactOS would adopt a BSD filesystem-to-rule-them-all then ntfs goes the way of the dodo.
        Some clever soul then slipstreams that code into your Win8 installer as a root fs driver and world domination ensues. :-)

    • This is done so that there is no risk of corrupting the NTFS File System. If you ask me, this is a good idea. What is so bad about simply copying the data you need onto your BSD4.4 File system?
    • by drolli (522659)

      a) yes it is hard to make a proper (*) file system "driver"

      b) its not getting easier by the file-system being closed source

      (*) proper here means: will under no circumstances behave in a way that you loose data trough silent corruption, as opposed to: will not normally loose data obviously after using if for a few hours.

      • by jack2000 (1178961)
        "driver", daemon, kernel module whatever the hell you want to call it.
        You know the source for that OS was leaked. I'm not saying developers should just outright copy it. Just look at the source off record and make your own implementation of it.
      • by leamanc (961376)

        Can't you just run a script to tighten up that loose data? It't not like you would *lose* data, would you?

    • Why is NTFS always read only. It shouldn't be so hard to make a proper file system driver what the hell?

      In FreeBSD you can enable write support and recompile your kernel, not sure about OpenBSD. I always wondered why default kernels in BSD and Linux don't just enable all well-supported filesystems to be available rw by default. Let the burden be on people who want the two second advantage in booting or something, rather than those of us who are trying to do something as basic as access our data.

    • by fuzzyfuzzyfungus (1223518) on Sunday May 01, 2011 @08:36PM (#35994184) Journal
      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.
  • All three OpenBSD users are thrilled.
    • by Anonymous Coward

      Stop, HAMMER time!

    • by rubycodez (864176)
      The works of the OpenBSD project are in each and every major open source OS and many major closed source ones as well.
  • Why 63? Because 64 would be just too KA-RAY-ZEE?
    • I'm kind of surprised that large-hardware support is that low. There are plenty of large RISC or mainframe commercial systems with more than 64 cores and 512GB.
    • by Anonymous Coward

      The two sides almost came to blows over whether to allocate four bits or eight bits in the descriptor for the CPU ID. Finally, after weeks of infighting they compromised at six bits, with one reserved value.

      from "Difficult: the Inside Story of OpenBSD" (unpublished)

    • by m.dillon (147925)

      Atomic ops are limited to 64-bits for the most part (though maybe 128 bits w/fp insns we can't really depend on that). There are several subsystems in the kernel which rely on atomic ops to test and manipulate cpu masks which would have to be reformulated.

      The main issue there is one of performance. We don't want to have to use a spinlock for cases where cmpxchg solves the problem because spinlock collisions can get VERY expensive once you have more than 8 cpus in contention.

      Similarly the stolen bit for th

      • 1000 watts is about what you need for a toaster. And the usual operating system for various toasters was always BSD, so what's not to like there?

        • by m.dillon (147925)

          Well, you don't run your toaster 24x7. In fact, most residental homes use less than 1000W of power averaged 24x7 for the entire home.

          Running 1000W 24x7 is ~$180-$240/month in electricty depending on where you live. Commercial power isn't much cheaper (and due to improvements in density most colo facilities now also charge for power or include only a few amps in the lowest-tier of service).

          It adds up fairly quickly. The DragonFly project has 7 core production machines. Six of those in my machine room tog

          • What sort of workloads do those machines see, is it amicable to distributing, say Web seed backed torrents? Have you investigated incremental compilation, and compiler caching?
  • ... just in time for Sony to rebuild the PSN. Hurray !
  • Back in the day - or rather the last time I was paying a lot of attention to /. - all BSD articles were flooded by that "BSD is dying... blah, blah confirms it" story (I believe the kids call it a "meme" but I am too old for that).

    Now they are not here: is this because they are blocked before they get posted or because it was one obsessive who died/finally had a beer/discovered masturbation or because the idea just, errr, died?

    Really interested to know what the answer to this one is.

    • by Impeesa (763920) on Sunday May 01, 2011 @09:28PM (#35994516)
      Netcraft confirms it, BSD jokes are dead.
    • by Rennt (582550)
      memes are supposed to die - and if you don't want the 'kids' to pick you for the fuzz you better quit it with the outdated jive, man.
  • I don't want to be a troll but seriously what is this 1998? At least they'll have cloud computing I guess...
  • I have been running Open for quite a while (2.8 I believe), but Dragonfly has gotten to the point where it has some interesting things to try. The Hammer file system and the MP lock. I may have to give it a spin. Got love the BSD crowd, different groups trying it their way! :)
  • by Anonymous Coward

    Yes I'm a FreeBSD person and no I'm asking an honest question. I've read the info on dragonfly but really where is the result? It split at the same point that I started on FreeBSD using 5.0 which he split it using the older 4 base.. The guy that forked dragonfly wanted to take a different approach to multiprocessing. I have to assume he knew something of what he was talking about. The project is mature enough, it's had years. Milticore processors are common now. So where are the benchmarks proving hi

    • by rubycodez (864176)
      DragonFly is still being designed, but the stated end goals are 1. Single system image clustering 2. providing multiple isolated environments in userland, 3. providing highly available clustered filesystem with multi-mastered mirroring/backup, de-duplication, snapshots
  • Hopefully VMWare will take notice of the good work being put onto vmt(4) and add official support to OpenBSD in ESX.

  • It is quite exciting to see an open source OS dedicated to providing the foundation for shared resources and a single system image for clusters. The goals of that project are usually accomplished with very expensive proprietary software, the Hammer fs is one huge such milestone.
  • Cheap replica watch site worth buying? http://www.aaawatches.net [aaawatches.net]

Never say you know a man until you have divided an inheritance with him.

Working...