4 ms·

David Miller is better known for spewing crap than he is for writing code, with good reason. When you feel the need to stir up shit by posting stuff like "durr

David Miller is better known for spewing crap than he is for writing code, with good reason. When you feel the need to stir up shit by posting stuff like "durr netbsd is doing stuff I did a decade ago" while ignoring the fact that netbsd also did it a decade ago and is just updating their implementation (just like linux does), you stop being someone worth listening to. It is pretty unfortunate that the dragonflybsd camp still insist on pushing deliberately misleading benchmarks, I must admit. They have a great OS and there is simply no need for them to be doing that shit. Refusing to adjust the default limits when you know full well netbsd and openbsd ship with conservative limits to prevent accidentally DoSing yourself on low end hardware is just plain stupid. "Oh look, netbsd mysteriously stops working right when we hit the default resource limits!"

ciupicri 14y ago
Nevertheless thread-local storage (TLS) and Logical Volume Manager (LVM) functionality have been available under Linux (and probably other BSDes) for quite some time. So that benchmark is kind of wrong. What about the results for fewer concurrent clients? NetBSD seems to perform worse than (Scientific) Linux. Is it because of those resource limits?
- papsosouid 14y ago
  TLS is not a feature, it is a problem. It was added because of the very problems that started this thread. Modern linux software expect stupid crap like that, so NetBSD eventually feels forced to add it. The entire point is that BSDs try to avoid adding unnecessary complexity like that. The dragonfly benchmark doesn't give us any real info, so it is impossible to say what exactly the problem is. Clearly something is wrong though, given we already know netbsd made performance and scalability a major focus of the 5.0 release, and nobody has reported any regressions in 6.0: http://www.netbsd.org/~ad/50/img13.html http://www.netbsd.org/~ad/50/img13.html

ciupicri 14y ago

Nevertheless thread-local storage (TLS) and Logical Volume Manager (LVM) functionality have been available under Linux (and probably other BSDes) for quite some time. So that benchmark is kind of wrong. What about the results for fewer concurrent clients? NetBSD seems to perform worse than (Scientific) Linux. Is it because of those resource limits?

papsosouid 14y ago
TLS is not a feature, it is a problem. It was added because of the very problems that started this thread. Modern linux software expect stupid crap like that, so NetBSD eventually feels forced to add it. The entire point is that BSDs try to avoid adding unnecessary complexity like that. The dragonfly benchmark doesn't give us any real info, so it is impossible to say what exactly the problem is. Clearly something is wrong though, given we already know netbsd made performance and scalability a major focus of the 5.0 release, and nobody has reported any regressions in 6.0: http://www.netbsd.org/~ad/50/img13.html http://www.netbsd.org/~ad/50/img13.html