OpenBSD 3.6 Live
An anonymous reader writes "There is a mounting excitement for the upcoming OpenBSD 3.6 release, as it is the first release that supports multiprocessor systems. To celebrate the event, ONLamp.com published an interview with several developers to discuss new features, tools, and future plans."
Well if you have enough to spare one, I'm sure a developer could use a multiproc sun box, check their wanted hardware list about donating one to further smp for sun.
Apache on OpenBSD always had a lot of security-related patches compared to the regular Apache (chroot for example), but it seems that Apache on OpenBSD can now be considered a real fork:
JP
The official release has just happened. Here are the official announcement, the undeadly.org thread and a torrent for the i386 binaries (149MB, matching MD5 which might beat some of the mirrors). Cheers ;)
Here's the original link... but now the page says: :-)
"This article has been removed because many points made within it have been deemed unfactual."
That was a lousy article indeed. The *BSDs deserve much better reviews.
The other BSDs have security levels. OpenBSD has a lot of things they don't, still, a large part of which is that it randomizes practically everything, making it very difficult for even a local attacker to know what the kernel is going to do next. They also yank out any external software that isn't getting properly treated against exploits, so their base package is still as firm as possible, and even ports are treated with great care.
In practice, FreeBSD and NetBSD are about as hard to exploit remotely, but they don't take care of every possible exploit, so in theory there are still some holes. NetBSD is still a lot faster than OpenBSD (unless some miracle happened and I missed it) so a 'real world' server might benefit more, but for a stronghold of impenetrable security that doesn't need every last drop of performance, OpenBSD is the choice.
Linux is nowhere near any of this. The code is sloppy and dirty (no, nobody can argue this, don't even try, just go read some yourself) and few distributions actually take security seriously. It does happen to perform better in many synthetic tests, and definitely on SMP, but the difference for most cases is so minimal that it's hard to understand why anyone would run Linux on a server and not a BSD.
I put it down to hype. Business love to advertise their adoption of Linux and their entrance into open-source, because that's what customers want to hear, especially Linux zealots. The businesses (hell, even governments now) certainly aren't scientific about it, using an "operating system" (I still call Linux a kernel, up to you) mashed together from seemingly infinite and inconsistent projects and parents'-basement-developed hacks. The source shows this, hell even configuration shows this, but they seem to be okay with this so long as it sounds good. Or, and I wouldn't be surprised, they've never heard of BSD.
Sam ty sig.
Not the case. You only need to do the compile on one, and distribute the binaries to the rest of your machines.
Why not? It's trivially easy. Merging old config files with new ones is the only thing you need to do maually. Config files don't change often, so it can be skipped, with little chance anything you run will have a problem.
Not like any other OS has the upgrade path perfected. You sure as hell don't dare upgrade your Windows machines. I don't know anybody that upgrades their Linux machines, at least no more than installing a few RPMs of newer programs. It's generally best to start clean with Linux.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
I'm assuming you're referring to the release(8) procedure which will generate base35.tgz, etc35.tgz, comp35.tgz, misc35.tgz, man35.tgz etc.
Now how large is base35.tgz? Approximately 30 megs? It doesn't make sense to transfer 30 meg updates to numerous machines to apply an update for just a couple of files that could have been 1 or 2 megs if smaller binary updates were available. Well atleast it doesn't to me anyway. I guess beggars can't be choosers. Although right now I primarily use FreeBSD so it doesn't have the simple .tgz archives.
DISCLAIMER: I'm not a developer
I read this comment in a mailing list. Wouldn't it be awesome if /usr/src tree would be structured in a way that /usr/ports is right now? So you could apply that radius source patch to your /usr/src tree and then
# cd /usr/src/net/radius
# make package clean
Resulting in radius_version.tgz which could easily be installed using existing pkg_* tools.
that statement demonstrates a complete lack of understanding about how openbsd, or any bsd, are developed, or even who is developing them.
If I combine the core teams, even the security teams of all the flavors COMBINED, we'll have a hard time finding programmers with stable jobs, let alone an advanced degree in the area or an industrial lab support.
... BSD has "Berkelely" in the name, and the university heritage lives on.
Are you serious? Here's a hint