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?
Is security(8) setuid? perl does a number of things to make setuid Perl scripts more secure than either setuid schell scripts or C programs (cf. taint mode).
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").
Work in progress to replace /etc/security, not yet linked to the build.
Main design goals:
1. Safely handle untrusted file names and file content.
2. Output compatibility with current security(8) to please people
parsing the output with scripts (except when improving functionality
right away saves considerable implementation effort). Substantial
functional enhancements are for later.
Prodding to do this in Perl by deraadt@.
Using some feedback from espie@.
The Radeon stuff is improving rapidly. You can't buy a diesel truck for the power and then complain that it won't take gasoline. ;-)
To hell w/ NVidia. If they won't play ball, I'll spend my money on an arguably slightly lesser performing product that is more open.
Though, currently the linux emulation layer in CURRENT has a change that broke the linux Flash binary. I've been flash-free for about 2 weeks now. I can't decide if that's a curse or liberation. Otherwise, I personally think FreeBSD is a mighty fine desktop OS. ZFS is really nice.
I never really saw BSD as a desktop operating system, regardless what OSX achieved with Darwin.
It made for an amazing mailserver last I tried it though. I used 3.4 on an ancient P4 with maybe 256MB of RAM an 8GB hard drive. Turns out that was way more computer than it needs, and it was so stable I began to think of it the same way I think of my router.
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.
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.
Yes, of course, but there is a general aim and focus among the developers of the three main flavors, that is prevalent in the capacities of said flavors:
With that said, no, that definitely does not mean that each flavor can't stand out in the other two fields. Heck, I used OpenBSD as my desktop OS for 2 years on and off, so I know very well how capable it is "off field", and looking at the most popular flavor in BSD-powered server parks we see FreeBSD instead of OpenBSD contrary to what logic might try to dictate.
There is support for kernel threads in the form of a flag on rfork(2). The golang port uses this. The pthreads library is still the shitty userland one though.
OpenBSD is great because the man pages aren't absolute shit like Linux and networking is so much better. Linux wifi drivers are absolute crap in comparison.
It's still a pretty usable desktop though. The new ACPI support is amazing and a completely new implementation, rather than being built on the reference implementation everyone else used.
> no 802.11n support
That's going to require some work on the 80211 layer.
> Configure WPA on OpenBSD: ifconfig <interface> nwid <ssid> wpa wpakey <wpakey> up; dhclient <interface>
The equivalent on linux is left as an exercise...
The "ip" command has been the preferred way to configure network interfaces in Linux for a few years now. Most functionality isn't available through "ifconfig" at all.
It's a mistake IMO for old hats like myself. After 20 years using ifconfig, it's almost impossible to get used to some new, linux-only tool (even though it may be better).
It's pretty rare that you actually need to use ifconfig/ip directly in Linux. For every distribution that I know of there's a specific way to setup network interfaces (e.g. /etc/network/interfaces, /etc/sysconfig/network-scripts/ifcfg-*, etc.)
>OpenBSD is great because the man pages aren't absolute shit like Linux and networking is so much better. Linux wifi drivers are absolute crap in comparison.
The problem with linux is that nobody owns responsibility for making the whole man system good.
Linux kernel stuff is covered by the linux man project. This is run by Kerrisk, who is a good communicator - _The Linux Programming Interface_ reads like Stevens but is richer in practical advice.
But if you go to the man page for something like awk or bash or grep (the common use-case - where you need a quick reference), they're maintained by the team who write the tool, or - often enough - not maintained by the team. There are undocumented flags, often the doc only tends to make sense if you already understand the internals of the tool. GNU tool man pages are generally obtuse.
BSD and plan 9 have much better man systems. Unless a linux distribution comes along and makes a conscious effort to solve GNU/linux doc, the man system available to linux users will always suck - it's structural.
"But if you go to the man page for something like awk or bash or grep [...]"
And this is where you are doing it wrong. For GNU tools, the man page is just a stub. The official documentation is maintained in the form of "info" pages.
Now, you may consider this obtuse (I sure do), but it doesn't mean there is no documentation.
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 aging, ~3 years behind mainstream
OpenBSD is doing quite well compared to the other BSDs. Intel and Amd graphic options are supported, depending on chipset, OpenGL works out of the box. KMS is being worked on from what I hear.
Nvidia and Adobe, well... they are a cancer and in a perfect world, would go bankrupt for their behaviour.
55 comments
[ 2.8 ms ] story [ 117 ms ] thread> Switched from the old shell script /etc/security to the new Perl script security(8).
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").
Work in progress to replace /etc/security, not yet linked to the build.
Main design goals: 1. Safely handle untrusted file names and file content. 2. Output compatibility with current security(8) to please people parsing the output with scripts (except when improving functionality right away saves considerable implementation effort). Substantial functional enhancements are for later.
Prodding to do this in Perl by deraadt@. Using some feedback from espie@.
http://www.openbsd.org/cgi-bin/cvsweb/src/libexec/security/s...
http://www.callfortesting.org/macpf/
- 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.
They all suffer from the good enough but not mainstream enough problem, i.e. official Nvidia drivers that are not officially supported.
To hell w/ NVidia. If they won't play ball, I'll spend my money on an arguably slightly lesser performing product that is more open.
Though, currently the linux emulation layer in CURRENT has a change that broke the linux Flash binary. I've been flash-free for about 2 weeks now. I can't decide if that's a curse or liberation. Otherwise, I personally think FreeBSD is a mighty fine desktop OS. ZFS is really nice.
It made for an amazing mailserver last I tried it though. I used 3.4 on an ancient P4 with maybe 256MB of RAM an 8GB hard drive. Turns out that was way more computer than it needs, and it was so stable I began to think of it the same way I think of my router.
And I don't think the users of other BSDs have much need for 3D acceleration..
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?
NetBSD - portability. OpenBSD - security. FreeBSD - performance and usability.
With that said, no, that definitely does not mean that each flavor can't stand out in the other two fields. Heck, I used OpenBSD as my desktop OS for 2 years on and off, so I know very well how capable it is "off field", and looking at the most popular flavor in BSD-powered server parks we see FreeBSD instead of OpenBSD contrary to what logic might try to dictate.
There is support for kernel threads in the form of a flag on rfork(2). The golang port uses this. The pthreads library is still the shitty userland one though.
OpenBSD is great because the man pages aren't absolute shit like Linux and networking is so much better. Linux wifi drivers are absolute crap in comparison.
Configure WPA on OpenBSD: ifconfig <interface> nwid <ssid> wpa wpakey <wpakey> up; dhclient <interface>
The equivalent on linux is left as an exercise...
It's still a pretty usable desktop though. The new ACPI support is amazing and a completely new implementation, rather than being built on the reference implementation everyone else used.
> no 802.11n support
That's going to require some work on the 80211 layer.
The 80211 guy retired so there's little chance of that happening.
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'm willing to wager that 10 years from now - configuring an interface will still be done through ifconfig.
For example?
I like Linux in practice, but one must admit that BSDs' manuals are way better.
Linux kernel stuff is covered by the linux man project. This is run by Kerrisk, who is a good communicator - _The Linux Programming Interface_ reads like Stevens but is richer in practical advice.
But if you go to the man page for something like awk or bash or grep (the common use-case - where you need a quick reference), they're maintained by the team who write the tool, or - often enough - not maintained by the team. There are undocumented flags, often the doc only tends to make sense if you already understand the internals of the tool. GNU tool man pages are generally obtuse.
BSD and plan 9 have much better man systems. Unless a linux distribution comes along and makes a conscious effort to solve GNU/linux doc, the man system available to linux users will always suck - it's structural.
And this is where you are doing it wrong. For GNU tools, the man page is just a stub. The official documentation is maintained in the form of "info" pages.
Now, you may consider this obtuse (I sure do), but it doesn't mean there is no documentation.
Case in point: check the output of lsmod. How many of those modules have a corresponding manpage? My guess: zero.
Same question for a BSD system (with lsmod changed to kldstat or whatever): all of them.
"""FreeBSD 8.X and prior is using the same version of PF as OpenBSD 4.1. FreeBSD 9.X and later is using the same version of PF as OpenBSD 4.5.""" [1]
[1]: http://www.freebsd.org/doc/handbook/firewalls-pf.html
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 aging, ~3 years behind mainstream
OpenBSD is doing quite well compared to the other BSDs. Intel and Amd graphic options are supported, depending on chipset, OpenGL works out of the box. KMS is being worked on from what I hear.
Nvidia and Adobe, well... they are a cancer and in a perfect world, would go bankrupt for their behaviour.