I'd still recommend SuSE for the desktop -- but I really can't justify calling anyone using OpenBSD as a desktop crazy either. It just isn't a big freak'n deal.
No big deal for most, unless one wants top performance 3D. One difference, though, is that OpenBSD has made many security enhancements to X, like privilege separation, removing suid-bit from xterm and xconsole, compiling X with ProPolice (to lessen danger of buffer overflow exploits).
That depends. OpenBSD has patched XFree86 to make it more secure. Among things they have done is to use privilege separation for X, so not the entire X needs to run as root.
They also made a ptm device that allows non-privileged processes to allocate a properly-permissioned pty, so the suid bit is removed from xterm and xconsole. Recently, OpenBSD made X work after enabling ProPolice for it, thus making buffer overflows less of a danger.
Re:Hardware Issues
on
Moving To Linux
·
· Score: 2, Insightful
Might add the fact that kernel 2.6 is incompatible with a lot of older hardware.
Not on OpenBSD, that is for sure. And the same is most likely for the other *BSD. New code will not be introduced if it will break existing installations, and if it breaks, they fix it. As an example, when OpenBSD made changes on i386 so that you could boot with kernel above 8GB on the harddisk, alot of testing and effort went into _making sure_ that nothing breaks. This included testing on ancient 386/486 machines.
One of the main issues with Linux Live CD's is the fact that it is rare for a live cd to properly initialize ALL the hardware on the computer.
Not very likely this is going to happen anytime soon. When some new hardware is inserted, there will be some probing by the kernel. And if the hardware is not recognized, you can see output like:
(manufacturer 0x0, product 0x0) vendor "3Com", unknown product 0x6000 (class network subclass miscellaneous, rev 0x15) at cardbus1 dev 0 function 0 not configured
In this case the vendor was known, but the product unkown. It happens to be a OfficeConnect 11Mpbs Wireless LAN 3CRSHPW796 using the ADMtek ADM8211 chipset. But unless the hardware detector is _told_ that is this, in fact, an ADM8211 chipset based wireless card, it can't use the correct driver. So we patch the kernel, and get
atw0 at cardbus1 dev 0 function 0: 3Com 3CRSHPW796 802.11b, revision 1.5 : 3Com 3CRSHPW796 802.11b: irq 10 atw0: RFMD RF, RFMD BBP 802.11 address 00:0d:54:f8:47:97
Hmm...Since Helix has been open-sourced, what's to stop someone from porting it to Windows, so one could dispense with RealPlayer and all the goop it installs?
Agreed, far to many people critisize the outdatedness of stable. It is outdated because it is STABLE, that may seem obvious but most people just don't get it. I have NEVER had stable break itself with bad dependancies etc.
Just because some software is _stable_ does not imply it's _outdated_, and vica versa, of course. It might not be _bleeding_ egde, but it's still fairly current.
A couple of years ago, I bought the offical Debian 3.0 DVD. On the cover they says there are 8710 packages included. With so many packages, it's no wonder there are real challenges to keep this working. Even FreeBSD brag about the number of ports (over 10 000 now adays) available, but the honour is dubious.
OpenBSD has a smaller number of packages (about 2000 or so), and have two releases every year. So many important packages are fairly/very current at the time of release. At desktop I run -current, but I've got far less hassle than SuSE Linux Pro that I used to run before. With exception of running propetirary software, of course...
For the BSD vs. BSD showdown, remember that FreeBSD's fast IPsec stack (hardware accelerated) was taken from OpenBSD. I don't have data on how much else is from OpenBSD.
All of the *BSD share (port) code with each other, and this is a good thing. The OpenBSD packet filter PF is ported to FreeBSD, for example. OpenBSD has recently ported the FreeBSD 801.11b framework into current, and the driver for the wireless chipset ADMTek ADM8211 from NetBSD. NetBSD has implemented/dev/ptm based upon OpenBSD work, so now they can remove the suid bit from xterm.
This, and more, in just the last 6 months, with exception of pf on FreeBSD that is ongoing work.
What causes most people to gawk after seeing Linux is the text-mode installation -- which is just text menus, but still menus. (I've seen some installation programs that can make you wonder.. OpenBSD, I'm talking to you.)
One problem with the FreeBSD installer is that it's both an installer and a configuration tool with menues that does not remember previous settings that you have done.
The OpenBSD installer is just that : an installer. Post configuration is mostly done after installation.
I'm working towards a site-to-site VPN deployment (hubs and spokes, of course) and am debating FreeBSD vs. OpenBSD. IPSec, queueing and redundancy (dynamic routing, perhaps DBU, and something like CARP) are requirements.
OpenBSD now has IPSec with NAT-T working in current. Queueing on OpenBSD is with ALTQ integrated with PF, and, of course, CARP is already thre.
FreeBSD has imported pf from OpenBSD, and I think that they work on ALTQ as well. Not sure about CARP yet.
I hate lawyers as much as the next guy, but this is a good thing.
Gee, the "I hate XXX as much as the next guy, but..." is so very conductive to a constructive dialog. It clearly shows that you have a balanced view of the said hate object, and is dealing with the matter in a fair, considerate and informed way.
In any case, for the near future if you want to run a 64 bit operating system you will either be using one of the free Linux versions or the free download of Windows XP-64 beta.
You might have noticed that there are other 64 bit CPU's than AMD64 that are in wide use, and other OS than Linux suports AMD64.
Academics can be as dangerously biased as anyone else. A trawl through academic history in the 1930's and the whole sorry "arian race" saga shows just how easily 'academia' is corrupted.
BSD jail system is good, but falls far behind compared to Linux nowadays.
This may be the case, but for many Linux users these security improvements are not easily available since they are not supported by the major Linux distributions.
As an example,
OpenBSD supports and integrates various technologies out of the box, while similar technologies is
unavailable for most
Linux users. Unless you do a huge amount of work, and have the required knowledge to patch your system, of course.
It's like the old proverb "Better with one bird in the hand, than ten on the roof."
So, what major linux distributions, BSD variants, or other operating systems are still using the XFree86 code base? Is the transition essentially complete?
OpenBSD is still using the latest XFree86 4.4 release candidate with the old license+drivers. And
NetBSD incorporated XFree86 4.4 with the new license.
So there you have it. We have a media which is currently in the middle of a massive deviancy amplification spiral, and this frankly fucking stupid move by BT is just an upshot of that.
And along with this comes
advice
that is somewhat disturbing:
Young people must re-learn the old stranger = danger messages in a new context and use the anonymity of the Net to hide their real location.
I'm all for caution, but this "stranger = danger" advice is not a particulary helpful attitude to instill in children, if one wants to help brigde gaps between different groups.
Indeed, the support for Java on several platforms is not very good, in fact, it's quite bad. For Windows, and distros that are Sun Partners, you can have a working Java fairly easy. Now, try the same on OpenBSD, and you will experience the Sun "Open Source" license horror that includes registering and agreeing to some nasty EULA's before downloading needed (very, very big) files that is part of the port. So, in pure irony,.NET via Mono might very well be more portable.
They can now tell people: look we have 5 guys running FreeBSD, 5 guys running NetBSD, 5 guys running OpenBSD and 5 guys running DragBSD.
Since we can safely assume that the *BSD developers are running their own OS, this implies that the 5 developers are very, very productive! So all the thousands of GNU/Linux kernel hackers quite simply can't match the quality, stability and speed of what is done by the 5 (five) *BSD hackers. By the way, the *BSD hackers has to develop userland in addition to kernel work;-)
Slashdot Mirror
No big deal for most, unless one wants top performance 3D. One difference, though, is that OpenBSD has made many security enhancements to X, like privilege separation, removing suid-bit from xterm and xconsole, compiling X with ProPolice (to lessen danger of buffer overflow exploits).
That depends. OpenBSD has patched XFree86 to make it more secure. Among things they have done is to use privilege separation for X, so not the entire X needs to run as root. They also made a ptm device that allows non-privileged processes to allocate a properly-permissioned pty, so the suid bit is removed from xterm and xconsole. Recently, OpenBSD made X work after enabling ProPolice for it, thus making buffer overflows less of a danger.
Not on OpenBSD, that is for sure. And the same is most likely for the other *BSD. New code will not be introduced if it will break existing installations, and if it breaks, they fix it. As an example, when OpenBSD made changes on i386 so that you could boot with kernel above 8GB on the harddisk, alot of testing and effort went into _making sure_ that nothing breaks. This included testing on ancient 386/486 machines.
Perhaps try a more stable OS?
Not very likely this is going to happen anytime soon. When some new hardware is inserted, there will be some probing by the kernel. And if the hardware is not recognized, you can see output like :
In this case the vendor was known, but the product unkown. It happens to be a OfficeConnect 11Mpbs Wireless LAN 3CRSHPW796 using the ADMtek ADM8211 chipset. But unless the hardware detector is _told_ that is this, in fact, an ADM8211 chipset based wireless card, it can't use the correct driver. So we patch the kernel, and get
Much better :-)
The most important part, the codecs, are still binary. I could care less for the player, if the codecs was freely available.
Erh, US law does not apply outside USA. But with Bush Jr. in power, I suppose you can be forgiven this misunderstanding.
The codecs are still binary, so there you are.
Just because some software is _stable_ does not imply it's _outdated_, and vica versa, of course. It might not be _bleeding_ egde, but it's still fairly current.
A couple of years ago, I bought the offical Debian 3.0 DVD. On the cover they says there are 8710 packages included. With so many packages, it's no wonder there are real challenges to keep this working. Even FreeBSD brag about the number of ports (over 10 000 now adays) available, but the honour is dubious.
OpenBSD has a smaller number of packages (about 2000 or so), and have two releases every year. So many important packages are fairly/very current at the time of release. At desktop I run -current, but I've got far less hassle than SuSE Linux Pro that I used to run before. With exception of running propetirary software, of course...
All of the *BSD share (port) code with each other, and this is a good thing. The OpenBSD packet filter PF is ported to FreeBSD, for example. OpenBSD has recently ported the FreeBSD 801.11b framework into current, and the driver for the wireless chipset ADMTek ADM8211 from NetBSD. NetBSD has implemented /dev/ptm based upon OpenBSD work, so now they can remove the suid bit from xterm.
This, and more, in just the last 6 months, with exception of pf on FreeBSD that is ongoing work.
The *BSD is alive and kicking, and sharing.
One problem with the FreeBSD installer is that it's both an installer and a configuration tool with menues that does not remember previous settings that you have done.
The OpenBSD installer is just that : an installer. Post configuration is mostly done after installation.
OpenBSD now has IPSec with NAT-T working in current. Queueing on OpenBSD is with ALTQ integrated with PF, and, of course, CARP is already thre.
FreeBSD has imported pf from OpenBSD, and I think that they work on ALTQ as well. Not sure about CARP yet.
Gee, the "I hate XXX as much as the next guy, but ..." is so very conductive to a constructive dialog. It clearly shows that you have a balanced view of the said hate object, and is dealing with the matter in a fair, considerate and informed way.
You might have noticed that there are other 64 bit CPU's than AMD64 that are in wide use, and other OS than Linux suports AMD64.
FreeBSD supports AMD64, and so does NetBSD.
Also OpenBSD supports it, but the support is even better in current. In addition, OpenBSD will use the NX-bit to increase security.
Here is an article, The Corruption (and Redemption) of Science , about more recent problems in science. But some of those problems, like funding, appears to be age old....
This may be the case, but for many Linux users these security improvements are not easily available since they are not supported by the major Linux distributions.
As an example, OpenBSD supports and integrates various technologies out of the box, while similar technologies is unavailable for most Linux users. Unless you do a huge amount of work, and have the required knowledge to patch your system, of course.
It's like the old proverb "Better with one bird in the hand, than ten on the roof."
My wife bought a pregnancy test, and that's even more scary ;-)
They use the last 4.4 *release candidate* with the old license. Looking at /var/log/XFree86.log on my OpenBSD workstation :
OpenBSD is still using the latest XFree86 4.4 release candidate with the old license+drivers. And NetBSD incorporated XFree86 4.4 with the new license.
KDE runs just fine on *BSD as well. In fact, I'm using KDE on OpenBSD. Just in case you are considering other free alternatives to Linux :-)
And along with this comes advice that is somewhat disturbing:
Young people must re-learn the old stranger = danger messages in a new context and use the anonymity of the Net to hide their real location.
I'm all for caution, but this "stranger = danger" advice is not a particulary helpful attitude to instill in children, if one wants to help brigde gaps between different groups.
Indeed, the support for Java on several platforms is not very good, in fact, it's quite bad. For Windows, and distros that are Sun Partners, you can have a working Java fairly easy. Now, try the same on OpenBSD, and you will experience the Sun "Open Source" license horror that includes registering and agreeing to some nasty EULA's before downloading needed (very, very big) files that is part of the port. So, in pure irony, .NET via Mono might very well be more portable.
So now "rm -fr /" won't work even as root as it will properly give you :
So there you are, you pesky root of all evil. Oh bummer, now I can't make any new files in /home/dude ....
Not on Microsoft Windows, it seems. From the article it's even better if the virus writer is sloppy.
Hope that includes making it smaller as well since it takes an awful long time just to load on an older laptop.
Since we can safely assume that the *BSD developers are running their own OS, this implies that the 5 developers are very, very productive! So all the thousands of GNU/Linux kernel hackers quite simply can't match the quality, stability and speed of what is done by the 5 (five) *BSD hackers. By the way, the *BSD hackers has to develop userland in addition to kernel work ;-)