4 ms·

>If you think that the OpenBSD has it right, why don't you use it as a desktop, too? Because I need to run windows applications. >Why aren't you running a vir

>If you think that the OpenBSD has it right, why don't you use it as a desktop, too? Because I need to run windows applications. >Why aren't you running a virtual machine of Windows 7 under OpenBSD? Because my laptop already had windows 7 on it, why install two OSes when I can install one? >Linux is complex because sometimes it has too be No, using complexity to justify further complexity does not mean it has to be that way. >Should I also mention the better multi-processor support? That has nothing to do with simplicity though. NetBSD is also simple, and it has SMP support as good as linux does. I am just using openbsd because fine grained locking is un-noticable for a dev box, and openbsd comes with better package management than netbsd. >Regarding the desktop, I strongly recommend watching "27c3 - Desktop on the Linux... I'm not very far through, but I have no idea why you think I should be watching this? Is there a particular time I can jump to where something relevant happens?

ciupicri 14y ago
I'm not familiar enough with NetBSD, but David Miller from Red Hat said "I love NetBSD releases, because their new feature lists help remind me what I implemented a decade ago." [1]. I've also found a benchmark done by the DrangFlyBSD guys[2]: The tests were performed using system defaults on each platform with pgbench as the test client with a scaling factor of 800. The test system in question was a dual-socket Intel Xeon X5650 with 24GB RAM. NetBSD 6.0 was unable to complete the benchmark run. That video shows that things aren't as simple as one might think, at least on the desktop. [1] https://plus.google.com/101384639386588513837/posts/ZD5ZhZ2FJLk https://plus.google.com/101384639386588513837/posts/ZD5ZhZ2F... [2] http://www.dragonflybsd.org/performance/ http://www.dragonflybsd.org/performance/
- papsosouid 14y ago
  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

I'm not familiar enough with NetBSD, but David Miller from Red Hat said "I love NetBSD releases, because their new feature lists help remind me what I implemented a decade ago." [1]. I've also found a benchmark done by the DrangFlyBSD guys[2]: The tests were performed using system defaults on each platform with pgbench as the test client with a scaling factor of 800. The test system in question was a dual-socket Intel Xeon X5650 with 24GB RAM. NetBSD 6.0 was unable to complete the benchmark run. That video shows that things aren't as simple as one might think, at least on the desktop. [1] https://plus.google.com/101384639386588513837/posts/ZD5ZhZ2FJLk https://plus.google.com/101384639386588513837/posts/ZD5ZhZ2F... [2] http://www.dragonflybsd.org/performance/ http://www.dragonflybsd.org/performance/

papsosouid 14y ago
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