Live data from Hacker News

OpenBSD 5.0 Released

openbsd.org

31–40 of 56 posts

Re: OpenBSD 5.0 Released

#31
post #27

Earlier quoted context omitted.

I was just throwing out some desktop-specific things at the end and have no interest in running any BSD as a desktop anymore. They all suffer from the good enough but not mainstream enough problem, i.e. official Nvidia drivers that are not officially supported.

Nvidia actually provides drivers for FreeBSD, which have worked well for me so far. Nothing on the ATI side, though. And I don't think the users of other BSDs have much need for 3D acceleration..

Eh? I run OpenBSD as a "desktop" and I use 3D acceleration to play 3D games and all that stuff. Even playing videos these days requires DRI support in the kernel. With a bit of careful hardware selection, 3D acceleration works out of the box on OpenBSD.

Re: OpenBSD 5.0 Released

#32
post #29

Earlier quoted context omitted.

> Configure WPA on OpenBSD: ifconfig nwid wpa wpakey up; dhclient The equivalent on linux is left as an exercise... wpa_passphrase > /etc/wpa_supplicant.conf wpa_supplicant -i -c/etc/wpa_supplicant.conf -B dhclient Everything is easy when you know how to do it.

On OpenBSD, all of your interface configuration is done with ifconfig and it's all documented with 'man ifconfig'. On a linux system 'man ifconfig' doesn't even mention iwconfig or wpa_supplicant. I think that makes it a little easier to learn how to do it.

I guess in Linux ifconfig is deprecated in favor of iproute2.

Re: OpenBSD 5.0 Released

#33

Earlier quoted context omitted.

OpenBSD was never meant to be a desktop BSD. You should take a look at FreeBSD instead.

I was just throwing out some desktop-specific things at the end and have no interest in running any BSD as a desktop anymore. They all suffer from the good enough but not mainstream enough problem, i.e. official Nvidia drivers that are not officially supported.

You said it best the first time when you said you missed pf.

Re: OpenBSD 5.0 Released

#35
post #18

I used to love OpenBSD but I've had to abandon it: - no sendfile implementation to accelerate web servers - ancient userland pthread implementation - worst SMP implementation of any mainstream OS - no unified buffer cache - no working TRIM support - no 802.11n support - video card drivers aging, ~3 years behind mainstream - no adobe flash support / hackarounds The only thing I really miss is PF.

If you're missing pf you might check out Debian/KFreeBSD. http://wiki.debian.org/Debian_GNU/kFreeBSD

Plain FreeBSD has also had pf since 2003. OSX also comes with it.

Re: OpenBSD 5.0 Released

#36

I used to love OpenBSD but I've had to abandon it: - no sendfile implementation to accelerate web servers - ancient userland pthread implementation - worst SMP implementation of any mainstream OS - no unified buffer cache - no working TRIM support - no 802.11n support - video card drivers aging, ~3 years behind mainstream - no adobe flash support / hackarounds The only thing I really miss is PF.

OpenBSD was never meant to be a desktop BSD. You should take a look at FreeBSD instead.

> OpenBSD was never meant to be a desktop BSD.

Where would people find this out? Has anyone listed the BSDs and said which task each was meant for? Are there any good BSD-to-BSD comparisons being done now?

Re: OpenBSD 5.0 Released

#37
post #36

Earlier quoted context omitted.

OpenBSD was never meant to be a desktop BSD. You should take a look at FreeBSD instead.

> OpenBSD was never meant to be a desktop BSD. Where would people find this out? Has anyone listed the BSDs and said which task each was meant for? Are there any good BSD-to-BSD comparisons being done now?

Lots of people have listed the BSDs and said which task each was meant for. Lots of people have also been completely wrong. There's a whole internet of misinformation out there if you're really interested.

Re: OpenBSD 5.0 Released

#38
post #29

Earlier quoted context omitted.

On OpenBSD, all of your interface configuration is done with ifconfig and it's all documented with 'man ifconfig'. On a linux system 'man ifconfig' doesn't even mention iwconfig or wpa_supplicant. I think that makes it a little easier to learn how to do it.

I guess in Linux ifconfig is deprecated in favor of iproute2.

Another advantage to OpenBSD - For at least the last 10 years, configuring a network interface has been done through ifconfig.

I'm willing to wager that 10 years from now - configuring an interface will still be done through ifconfig.

Re: OpenBSD 5.0 Released

#39
post #19

I used to love OpenBSD but I've had to abandon it: - no sendfile implementation to accelerate web servers - ancient userland pthread implementation - worst SMP implementation of any mainstream OS - no unified buffer cache - no working TRIM support - no 802.11n support - video card drivers aging, ~3 years behind mainstream - no adobe flash support / hackarounds The only thing I really miss is PF.

> - ancient userland pthread implementation Indeed, being worked on with rthreads. > - worst SMP implementation of any mainstream OS There's slow progress to push back the kernel biglock. > - no unified buffer cache Very few people have a justifyable need for a synchronous cache between read()/write() and mmap(). > - no working TRIM support Is available in -current, not sure about this release. > - video card drivers…

There is no current TRIM support I'm aware of, but it could possibly ship in 5.1. Or 6.1. Who knows.

Re: OpenBSD 5.0 Released

#40
post #20
post #3

My favourite bit from the (as always, impressive) changelog: For additional security, security(8) was rewritten in Perl.

That reason seems pretty shallow coming from the OBSD team... How can changing the language make it more secure by itself? Is a rewrite in C the next planned enhancement?

At the risk of dumping yet more karma, let me rephrase more constructively. OpenBSD has focused on security from the beginning. Precisely for that reason, and considering all the audits they run, it feels like, if OpenBSD has used (up to 4.9) shell scripts for security(8), there mustn't be any compelling reason against using the shell. Surely they must not have them.

I realize this was a changelog and not an article, and probably due reasons were found and discussed by the team. I still feel, nonetheless, that "For additional security, security(8) was rewritten in Perl" is either too short (provide a brief reason such tedunangst's) or too long (omit half-baked reasons and simply provide the fact that "security(8) was rewritten in Perl").

Post reply on HN