31–40 of 40 posts
Am I the only one who suspects a high number of commits is a sign of good programming, and by induction good programmers?
Earlier quoted context omitted.
I've toyed with it, not sure if that qualifies as "used". As a DC sysadmin I live off backports and patches (CentOS). 99% of our deployed OSes are all supported a long (to very long) time.
I used to do that but having had certain duff kernels and SMB packages out of RH, they can go to hell. This one took out our SMB/CIFS implementation in CentOS 6.2 forcing us to grab some windows licenses in the end (which I will add has been damn reliable): https://bugzilla.redhat.com/show_bug.cgi?id=476442 Still broken in CentOS 6.5 and Centos 7.0. Many people have raised this issue (google it) and it's always "fixe…
How much did you pay for CentOS? Perhaps if more people were willing to pay for RedHat and/or Samba, some of the more obscure bugs would more readily get fixed.
In the general case, developers need to put food on their dinner table and put a roof over their heads. Good quality "free" software only goes so far, OpenBSD pulls it off because they limit the scope of their efforts.
So, instead of complaining about CentOS, buy some RedHat licenses. The end result might not be any different but you'll at least have paid for the right to complain.
For those who have heard of OpenBSD but have not used it, I strongly recommend trying it on your next server appliance. I have been using it on my servers for some time now and I have been very happy. The entire OS seems to be of substantially higher quality than Linux.
Also things are deceptively simple. There's of course the initial hiccup for new users since the setup is a tad esoteric, but once past that, using it is very straightforward. It's not quite "set it and forget it" for servers, but pretty close IMHO. There's an attitude among the developers of making it extremely difficult to run sub-par code on the OS, which makes the overall quality of most ported apps high, quite s…
A buddy of mine is an overworked (and underpaid) sysadmin for a small ISP, and commented the other day that the OpenBSD firewall that I built for them 7 years ago (!) is still humming along nicely, they're still using and tuning its rulesets, and it wasn't vulnerable to shellshock.
(This isn't to say that not updating a firewall for 7 years is good practice, obviously. I shouldn't have to say that, but HN.)
It's amusing that commit 300,000 fixes a buffer overflow. It's a demonstration that large C programs do not converge to the state of having no buffer overflows.
Earlier quoted context omitted.
> The entire OS seems to be of substantially higher quality than Linux. That's a pretty bold statement. Care to elaborate?
As a long time lurker, I'm going to jump on this one. Yes it is bold by the user but I agree entirely. I spent the best part of a decade running Solaris and Linux machines from 1998-2008. The Solaris kit was easy to keep running once you'd got over the initial configuration hell and was very stable. The Linux stuff however was nasty at best. From CIFS/SMB crashes taking out the VFS layer to drivers packing in to inco…
Earlier quoted context omitted.
> The entire OS seems to be of substantially higher quality than Linux. That's a pretty bold statement. Care to elaborate?
Sure. Everything is more reliable. Not one crash yet. When I use Linux, I would have expected several by now. Everything works perfectly out of the box and has sane and safe defaults. Everything is more consistent. For example, the ifconfig/iwconfig/wpa_supplicant/etc. mish-mash on Linux is replaced with just ifconfig. All interactions with the OS are straightforward and standardized. The code is substantially better…
Also true with Linux, of course.
> Everything works perfectly out of the box and has sane and safe defaults.
Same with Linux, at least in the distros I use.
> Everything is more consistent. For example, the ifconfig/iwconfig/wpa_supplicant/etc. mish-mash on Linux is replaced with just ifconfig. All interactions with the OS are straightforward and standardized.
"My way or the highway", in other words. Use the Only OpenBSD Toolkit or get out?
> The code is substantially better. Less macrotanium, better naming, more understandable.
Readability is subjective. Macros aren't inherently bad.
> There is clearly more attention to (and more expertise about) security. This is, of course, what OpenBSD is (rightfully) known for.
At the expense of everything else, it seems, including hardware support.
Am I the only one who suspects a high number of commits is a sign of good programming, and by induction good programmers?
But, to be fair, everything is a sign of bloat.
Earlier quoted context omitted.
sysjail is available for OpenBSD. >It provides a similar function as FreeBSD's jail(8) utility while being significantly more flexible. The package provides jail(1), a drop-in replacement of FreeBSD's jail(8) http://sysjail.bsd.lv/
sysjail is not safe for jail-like use. Sysjail'ed processes can do Bad Things by exploiting concurrency races in the syscall interception layer. Relevant paper: http://www.watson.org/~robert/2007woot/2007usenixwoot-exploi...
Earlier quoted context omitted.
sysjail is not safe for jail-like use. Sysjail'ed processes can do Bad Things by exploiting concurrency races in the syscall interception layer. Relevant paper: http://www.watson.org/~robert/2007woot/2007usenixwoot-exploi...
This paper is from 2007, is it still not fixed?
Earlier quoted context omitted.
This paper is from 2007, is it still not fixed?
It's my understanding that it's not fixable without some help from the kernel. The fundamental problem is that a program can race ahead of a userspace syscall policy enforcement framework (i.e. sysjail) by trapping to the kernel directly. The authors identify several ways this can be exploited to gain privileged information or invoke syscalls the OS allows but the framework tries to prevent.
Learned something new today thanks :)