The new release includes new USB stack (USB4BSD), which supports USB3; updated video drivers for Intel and AMD cards (although latter are still disabled by default); binaries in /bin and /sbin are now dynamic, allowing for PAM and NSS. The HAMMER2 filesystem is also included, but not ready for general use just yet.
The 32bit edition is now deprecated. Reflects that they are targeting newer server roles.
Reflect that is extra work to maintain x86 that a few cares of. I’m personally still working on x86 OS-es, but lets face it: it’s nearly over.
Sadly this is making all of my old PC servers slowly obsolete.
Why? There’s tons of stable software that will run on them, surely. Just because the latest-greatest tech doesn’t run on your servers any more, it does not mean they are obselete.
charlieg,
Hmm, isn’t that exactly what it means? Old hardware can still be useful, particularly for running old software, but without the ongoing support of software venders, it becomes obsolete even if it still technically works. Now saying that DragonFly BSD is the nail in the coffin would be a bit silly, but I would agree with gods_design’s statement that “Sadly this is making all of my old PC servers slowly obsolete.”
Well OpenBSD still supports freaking VAXen from the 1970s, so your 32-bit x86 servers will have a nice Free *nix for many years to come.
tidux,
Yea, 32bit x86 has more years in it yet. It will continue disappearing slowly though, the majority being trashed/recycled, others will end up in storage (aka attic) like commodores/atari/bbc/etc.
I find the OpenBSD dev’s commitment to VAX fascinating. I had read how they themselves have a great deal of trouble getting VAX hardware for internal testing. Although it is a cool novelty to have these old machines that are still running, it would be insane to actually rely on said hardware for anything at all.
Edited 2014-06-06 21:18 UTC
It’s also a silly waste of time and effort IMO, given how resource-constrained these type of projects are. But hey, it’s their own time and effort, so they should do whatever it is they want with it really.
Edited 2014-06-06 21:23 UTC
tylerdurden,
Spot on. I don’t mind in the least that they want to work on it. If they are able to bankroll the operation, then that’s entirely their prerogative. On the other hand, given their recent financial difficulties, I can’t help but think it is irresponsible to divert resources to archaic platforms that so few will benefit from.
Back when OpenBSD asked for money to keep that great operating system going, many people, instead of donating, contributed worthless ideas about how the project could save money (including building their own power plant). One of the ideas was to drop VAX support. As I remember it, the project’s response was basically this: 1. VAX doesn’t actually incur significantly more expenses than any other platform. 2. Even though few people may actually use the Vax or other esoteric ports, it benefits everyone because it lets the developers find bugs that are only easily seen on these architectures. Also, for what it’s worth, the OpenBSD project has dropped a few unused and unneeded ports over the last year or two; it’s not like they are incapable of change or something.
I think it was clear from either of our responses that whatever people want to do with their time and effort is their prerogative.
That being said, the reasons given regarding their support of ancient architectures is hand wavy at best. Just say that you do it because you can or like, and be done with it…
IsakWatertroll,
Well, to be fair, a $20k/year on electricity alone is too much for such a small project.
The fact that openbsd was looking for a corporate sponsor to take on the electricity bill indefinitely tells me that even they know they have a major reoccurring funding problem, and yet the stubbornness of devs to even consider solutions is extremely off-putting to would-be donators who like to see their money being put to good use and not being wasted.
Haha, I hadn’t heard that, but I agree it’s a bit silly
But VAX *does* incur significantly more expenses relative to it’s share of the user base. In other words users of ordinary platforms are subsidizing the esoteric ones.
I’m not convinced that this is as important as openbsd devs made it out to be. For one thing, a physical machine isn’t needed to test for the kinds of architecturally exposed coding problems we’re talking about here (variable alignment, endianess, stack corruption) emulators would work just as well at exposing these kinds of problems. Even if the emulators are imperfect, they can still run the physical machines from time to time without burning through energy 24*7.
Code analyzers are designed to catch these kinds of problems too, even at compile time!
https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis
Still, we can all agree that what they do is their prerogative.
Out of curiosity, what platform are you referring to?
http://www.openbsd.org/plat.html
The last abandoned platform I see on this list is a palm in 2009, but it appears that it was a “semestral project” anyways.
Edited 2014-06-07 00:45 UTC
As far as I remember there was an extortion like behavior from developers who insisted on support for those old systems or they would quit.
You are right about bugs, there were not a single one episode were a bug was found due to different hardware, but there was as an example code which was a hack to make code running due to originally bugged hardware – which is not a bug of OS.
I have to add, that when LibreSSL was created devs stripped code for old OSs, which is very against their logic of different systems help to find bugs, although in this case it is software not hardware, but still it is strange.
I have no recollection of anything like that happening and I have been following OpenBSD since 2001.
Besides, there’s really only miod@ (and maybe one or two more people) who works on Vaxen and he’s not paid to do so.
Really? Are you an OpenBSD developer? If not, how would you know?
There’s old and there’s ancient and besides, why would libressl support architectures that OpenBSD does not support? What, they should start spending money on as400 and 16bit Windows boxes and finding developers who cares about these platforms?
Edited 2014-06-09 06:13 UTC
Well, 32 bit has been obsolete in my line of work for a good 7 years or so. That 4 GB memory limit is killer. PAX or no PAX.
Bill Shooter of Bul,
What is your line of work?
Personally my desktop only has 4GB and it rarely uses that because I don’t need much for web development. However I realize visual studio / eclipse are real memory hogs, 8GB would be better for those applications, or large multimedia projects obviously.
I do provision servers with a lot more ram though in order to run many VMs. To be honest I think 32bit + PAE could do the trick there since the VMs are < 4GB anyways. I even think running 32bit OS in a VM may be slightly advantageous in terms of getting more to fit in ram and CPU cache. But never the less I migrated all my client VMs to 64 bit because running a homogenous 64bit environment is just easier.
For servers, I do think 4 GB is too low for non trivial work. If you are just running a simply proxy server or SMTP server, then that would probably be fine. But if its part of an application cluster or database of some sort, add memory. Its a quick, easy, and cheap dramatic performance enhancer for most things. You’d be shocked at how cheap you can get a multi processor multi core 32 GB server from dell/HP. I still am.
I understand this is just a general rule of thumb, but if someone told me they were going 32 bit it would raise alarms* in my head.
* although I have a dream about building a cheap 32 bit arm farm for research/educational purposes. I think it could be great for prototyping.
NetBSD will never abandon you ;p