Well, I can't really recommend the "most" anti-industry dvd player, but I can recommend a place that seems dedicated to selling anti-industry dvd players in general. World-Import is the place to look if you are looking for anti-industry dvd players.
They have pretty good FAQs about this whole issue too. Mentioning, for instance, things like the need to support PAL-* and NTSC for the multiregion feature to be of any value.
FreeBSD once used the Mach VM. But large parts of that code has been altogether replaced. If you were to answer questions about FreeBSD VM based on Mach VM knowledge, you'd get most of the answers wrong.
For this reason, I don't think saying FreeBSD uses a "hacked" Mach VM is correct.
As for UCB having been integrated, *not* at the time I wrote the message, you cheater!:-)
No, I'm not saying there are not assholes among developers. Just that there aren't any asshole developers on FreeBSD, NetBSD or OpenBSD.
As a matter of fact, all our developers have great personality, are intelligent, considerate, polite, well-meaning, charismatic and, generally speaking, perfect human beings. There you have, tons of trolling material.
I'm amused to notice, though, that you did not contest my statement that _you_ are an asshole.
As a more to the point reply of what is obviously a troll, I never said a developer could not be an asshole. I just implied that no NetBSD developer is anywhere near the giant, elephant-raped asshole that you are.
I doubt that Anonymous Coward is a NetBSD developer.
Users, sure, all BSD have their assholes, as do all Linux distributions, and, in fact, all Operating Systems, and all text editors and all computer languages, and etc, etc, etc, in all things in life from cars to soccer teams to whatever you can think of.
FreeBSD's VM is not a hack to death of Mach VM. The rest of the message just goes downhill from there.
As for "not knowing much about NetBSD's VM", I put in the UVM != Unified VM/buffer cache note to prevent people from saying NetBSD had "Unified" VM already.
And since UCB has *not* been merged yet, as you confirmed, it seems I'm still up to date with my info.
Actually, many BSDers *do* have a problem with restrictive licenses, and that's why they don't use Linux. Try suggesting on Open/Net/FreeBSD to replace a BSD-licensed util with a GPL-licensed one, for instance.
"But the BSD license let someone relicense it under a super-restrictive license," says someone.
Well, yeah. And, guess what?, we *don't use* that relicensed code, we stay with the BSD-licensed code.
What we don't have a problem with is other people using the code we created in whatever damned way they wish. That's the whole point of being non-restrictive.
You have the kernel. The kernel has a number of services, and a number of functions to do them.
You have the userland. The userland uses some libraries, and they, in turn, call the kernel to do some stuff.
Between them, this "call the kernel", is something named "syscalls". These are kernel "functions" that can be called from outside the kernel. They are the interface (in the _real_ CS sense of "interface") between kernel and userland.
Now... there is a large set of syscalls that is identical between most Unix, and there is a small set of syscalls that are different or unique to each OS. But these syscalls are _numbered_ differently.
So... what is the emulation, in the context of running Linux or FreeBSD binaries on OpenBSD (or NetBSD, since that's the focus of this story:)? Three things:
1) A numbering of syscalls identical to the OS being "emulated". There is *ZERO* speed difference here, because this is exactly what native applications do. The only difference between a native application and an imported binary is that different syscalls tables are selected depending on what is the binaries' type.
2) Some syscall "translation". This is the case where the native OS has a different order of arguments and/or more arguments or different flags values or some arguments/flags of the emulated syscall simply does not apply in the native OS. In this case, there simply is a call with the arguments reordered, and maybe some masking/translation of flags.
The cost of this is almost negligible, because the cost of *making* a syscall (crossing the userland/kernel border), in itself, is much greater already. Also, the different in speed of the *implementation* of said syscall will often far surpass, one way or another, this overhead.
3) Implementation of a feature non-existentent in the native OS. There is no overhead here, because there is no translation. The syscall is simply being implemented from the scratch. The implementation may be faster or slower than the emulated OS, because of the native OS' architecture. At the very least, Open Source means we can look at how the other OS implemented it.
And there you have. "Emulation", when used to speak of different hardware being emulated in software or different a different operating system being emulated, means slower. What is being done here is *not* emulation, but "ABI compatibility" just isn't catchy (or as easily understandable), so few people speak that way. What we do does _not_ add overhead.
As for databases and Java... Postgres and MySQL can be found in the ports (packages, on NetBSD) tree of all BSD. Java is more complicated, because it depends on a specific model of threads support. FreeBSD is, nowadays, mostly ok when it comes to Java (or so I'm told:). I do not know the state of Java on OpenBSD or NetBSD, but I'm afraid this specific application will not run emulated because it needs some very specific features support in the kernel. But don't take my word on it.
There is a lot of code going back and forth between the BSD. Net and Free copy security fixes from Open, Open copy stuff from Net and Free, bug fixes are often shared between them (an indication of the extent to which there _is_ common code), FreeBSD imported NetBSD's usb and cardbus support etc.
Since you did specifically mention VM, let's talk about that. FreeBSD did not and has no plans to replace it's VM with NetBSD's because, to put simply, FreeBSD's is better. For one thing, it's unified buffer cache/VM, and, last I heard of it, NetBSD hasn't unified theirs yet. For another, is has been carefully optimized through many years to both handle ultra heavy loads gracefully and not slow down lightly loaded systems. NetBSD simply isn't there yet.
So why didn't _NetBSD_ import FreeBSD's VM? Because NetBSD has a tendency to the experimental. The path they are taking is more modular and might, in time, become a better VM than FreeBSD's.
FreeBSD's goals effectively prevents them from taking such an experimental path with such an important and _proved_ subsystem. NetBSD's goals doesn't. And there, btw, you have why the BSD do not unify, _and_ why that is a good thing.
And last, but not least, these are monolythic kernels. You *can't* just replace the VM subsystem. It just doesn't work that way. The effort that would be required to change the VM subsystem is enourmous. That's why, for instance, NetBSD doesn't have the unified buffer cache/VM working yet (or didn't, last I heard).
Finally, as to code sharing, there just are disagreement as to how some things ought to be done. For instance, NetBSD has opted to go "newconfig" while FreeBSD decided to go "newbus". A lot of concepts _and_ some code for "newbus" came from NetBSD's work, which predated it. But FreeBSD developers had fundamental disagreement as to how this thing should work and, thus, went another way.
***
Final note: I once assumed UVM meant "unified" VM, as in unified VM/buffer cache; I was later told by a NetBSD committer that was not the case, and haven't heard of any news since. If the status quo is no longer that, I'd deeply appreciate if someone more familiar with NetBSD would correct me.
***
PS: yes, there is bad blood between OpenBSD and NetBSD. That's mostly because Theo de Raadt has a love-him-or-hate-him personality. That's just the kind of thing that can't be helped.
The one year estimate is for *prototypes*. Now, while people in the computer business have a tendency of confusing prototypes with the final product, that's not the case outside our field.
A prototype in one year looks pretty much a viable estimate. All technologies involved are well known, and it's "just" a matter of combining them.
The plan is not getting users to buy subscriptions. They'll sell this to computer makers, to be bundled with desktops and notebooks. This way, they force the users to either renew or buy Office after one year.
And this won't be a problem for the computer makers, because they won't _have_ any option. First, it will be cheaper, naturally. Second, Microsoft will railroad any opposing makers into accepting it. For instance, by simply not offering the unlimited version at lower prices.
You *wish* the official book was all you need. It isn't. There are scores of topics that are not documented in it and which are _specific_ to FreeBSD, and, thus, not covered by general Unix books (like books on bind, sendmail, *sh, etc).
Oh, come on now, all of you! Almost all new committers are selected simply for the patches they sent. Just check http://www.freebsd.org/support.html#gnats, and count the number of patches submitted by woman, and you'll see it is no "old boys club" that's preventing women from becoming committers.
There are female FreeBSD users, and a good many deal of them are experts in one cs field or another. Why none of them has ever come forth as a committer candidate, if nothing else... beats me.
They can certainly often be found on the secret virtual dens of FreeBSD committers around the net.
This is most easily done by sending enough Problem Reports (see send-pr(1)) that the poor bastards who get to commit all your stuff for you gets tired of it and asks the core team to have brought as a committer.
Committers usually fit in one of the following profiles:
1a. Doc Committers are documentation freaks who go through the handbook, the faq, the web site, the man pages, etc, and actually fix things, add things, etc. There are even the occasional maniacs who track down code hackers and extract, with the help of red hot irons, iron maidens and similar instruments, information required to document a feature.
Suggestion: read freebsd-questions. Make a note of frequently asked questions, and check the answers to it. Write the Q/A to the FAQ. send-pr(1).
1b. Ports committers. These are complete freaks who seems not to have a thing to do in life besides surf the Internet looking for the most arcane pieces of software, and the "port" them to FreeBSD.
Suggestion: look at the software you use that has yet to be part of the FreeBSD ports collection. Read the porters handbook. Follow the instructions in writing the port to FreeBSD (this is often very easy!). send-pr(1).
1c. The code hacker. These are the completely insane persons who go to the trouble of writing code to help the lives of hundreds of thousands or even millions of people around the world, often without getting a single thank you note of recognition. Not only that, but they are often being chased around by docs committers who make use of extremely painful methods to extract information about what they have just written, as if they could remember that! Well, not often enough, actually, but still...
Sugestion: Do you have a problem you need solving, a bug that needs fixing, or a feature you want? Well, write the code for it, and send-pr(1).
2. Become well-known. This is actually easily done. Subscribe and be vocal in -hackers, -current, -stable, -arch and, perhaps a few more choice lists such as -ports, -doc, -scsi, -fs, -mobile, -small, -questions, -chat, -advocacy, besides the ones you'll already find yourself subscribed to, like -committers.
You don't need to be a genius. Listen, present your opinion when an opinion is being asked for, and speak of technical matters when your knowledge enables you to. Never be afraid to ask. Try to avoid flame wars.
3. Candidate yourself to core. This can only be done once every two years, but there is no further requirement aside from being a (active?) committer.
Since you are a woman and there is little female blood around, chances are you'll get elected simply because of gender. Of course, that will happen IF people know you from the mailing lists and commit logs, and you haven't pissed off everyone. But since each committer gets nine votes, I'd wager the chances of them choosing to vote for you just to provide some "balance" is rather large.
1. People wasn't satisfied with the previous core team. No specific reason. Some grudges existed among some committers, but it was more a general feeling of dissatisfaction than anything specific.
2. People wanted to continue to have a core team. People was generally happy with the general organization, so there wasn't any need to a restructuring that would remove the core team altogether. As a matter of fact, most of those who expressed themselves believed that no other project has a better organization.
Thus, it was decided to change the core team. The method people seemed to prefer was elections, and after months of discussions and reviews and votes, this was done.
Slashdot Mirror
Because {Free,Net,Open}BSD are much more important to the Slashdot community than BSD/OS.
For one thing, anyone who wants can get the first three, just clicking on one of the URLs in the stories. The last one requires $$$.
Oh, man, why did I spent my last moderator point yesterday? This deserves to be moderated all the way up to 5! :-)
They have pretty good FAQs about this whole issue too. Mentioning, for instance, things like the need to support PAL-* and NTSC for the multiregion feature to be of any value.
FreeBSD once used the Mach VM. But large parts of that code has been altogether replaced. If you were to answer questions about FreeBSD VM based on Mach VM knowledge, you'd get most of the answers wrong.
:-)
For this reason, I don't think saying FreeBSD uses a "hacked" Mach VM is correct.
As for UCB having been integrated, *not* at the time I wrote the message, you cheater!
...I confused you with another Anonymous Coward. The risks of browsing flat...
For this reason, I retract my accusations of you being an asshole.
Boy, what a troll if I ever saw one.
No, I'm not saying there are not assholes among developers. Just that there aren't any asshole developers on FreeBSD, NetBSD or OpenBSD.
As a matter of fact, all our developers have great personality, are intelligent, considerate, polite, well-meaning, charismatic and, generally speaking, perfect human beings. There you have, tons of trolling material.
I'm amused to notice, though, that you did not contest my statement that _you_ are an asshole.
As a more to the point reply of what is obviously a troll, I never said a developer could not be an asshole. I just implied that no NetBSD developer is anywhere near the giant, elephant-raped asshole that you are.
I doubt that Anonymous Coward is a NetBSD developer.
Users, sure, all BSD have their assholes, as do all Linux distributions, and, in fact, all Operating Systems, and all text editors and all computer languages, and etc, etc, etc, in all things in life from cars to soccer teams to whatever you can think of.
FreeBSD's VM is not a hack to death of Mach VM. The rest of the message just goes downhill from there.
As for "not knowing much about NetBSD's VM", I put in the UVM != Unified VM/buffer cache note to prevent people from saying NetBSD had "Unified" VM already.
And since UCB has *not* been merged yet, as you confirmed, it seems I'm still up to date with my info.
Actually, many BSDers *do* have a problem with restrictive licenses, and that's why they don't use Linux. Try suggesting on Open/Net/FreeBSD to replace a BSD-licensed util with a GPL-licensed one, for instance.
"But the BSD license let someone relicense it under a super-restrictive license," says someone.
Well, yeah. And, guess what?, we *don't use* that relicensed code, we stay with the BSD-licensed code.
What we don't have a problem with is other people using the code we created in whatever damned way they wish. That's the whole point of being non-restrictive.
Let me explain here how does "emulation" work.
:)? Three things:
:). I do not know the state of Java on OpenBSD or NetBSD, but I'm afraid this specific application will not run emulated because it needs some very specific features support in the kernel. But don't take my word on it.
You have the kernel. The kernel has a number of services, and a number of functions to do them.
You have the userland. The userland uses some libraries, and they, in turn, call the kernel to do some stuff.
Between them, this "call the kernel", is something named "syscalls". These are kernel "functions" that can be called from outside the kernel. They are the interface (in the _real_ CS sense of "interface") between kernel and userland.
Now... there is a large set of syscalls that is identical between most Unix, and there is a small set of syscalls that are different or unique to each OS. But these syscalls are _numbered_ differently.
So... what is the emulation, in the context of running Linux or FreeBSD binaries on OpenBSD (or NetBSD, since that's the focus of this story
1) A numbering of syscalls identical to the OS being "emulated". There is *ZERO* speed difference here, because this is exactly what native applications do. The only difference between a native application and an imported binary is that different syscalls tables are selected depending on what is the binaries' type.
2) Some syscall "translation". This is the case where the native OS has a different order of arguments and/or more arguments or different flags values or some arguments/flags of the emulated syscall simply does not apply in the native OS. In this case, there simply is a call with the arguments reordered, and maybe some masking/translation of flags.
The cost of this is almost negligible, because the cost of *making* a syscall (crossing the userland/kernel border), in itself, is much greater already. Also, the different in speed of the *implementation* of said syscall will often far surpass, one way or another, this overhead.
3) Implementation of a feature non-existentent in the native OS. There is no overhead here, because there is no translation. The syscall is simply being implemented from the scratch. The implementation may be faster or slower than the emulated OS, because of the native OS' architecture. At the very least, Open Source means we can look at how the other OS implemented it.
And there you have. "Emulation", when used to speak of different hardware being emulated in software or different a different operating system being emulated, means slower. What is being done here is *not* emulation, but "ABI compatibility" just isn't catchy (or as easily understandable), so few people speak that way. What we do does _not_ add overhead.
As for databases and Java... Postgres and MySQL can be found in the ports (packages, on NetBSD) tree of all BSD. Java is more complicated, because it depends on a specific model of threads support. FreeBSD is, nowadays, mostly ok when it comes to Java (or so I'm told
In a word, bullshit.
There is a lot of code going back and forth between the BSD. Net and Free copy security fixes from Open, Open copy stuff from Net and Free, bug fixes are often shared between them (an indication of the extent to which there _is_ common code), FreeBSD imported NetBSD's usb and cardbus support etc.
Since you did specifically mention VM, let's talk about that. FreeBSD did not and has no plans to replace it's VM with NetBSD's because, to put simply, FreeBSD's is better. For one thing, it's unified buffer cache/VM, and, last I heard of it, NetBSD hasn't unified theirs yet. For another, is has been carefully optimized through many years to both handle ultra heavy loads gracefully and not slow down lightly loaded systems. NetBSD simply isn't there yet.
So why didn't _NetBSD_ import FreeBSD's VM? Because NetBSD has a tendency to the experimental. The path they are taking is more modular and might, in time, become a better VM than FreeBSD's.
FreeBSD's goals effectively prevents them from taking such an experimental path with such an important and _proved_ subsystem. NetBSD's goals doesn't. And there, btw, you have why the BSD do not unify, _and_ why that is a good thing.
And last, but not least, these are monolythic kernels. You *can't* just replace the VM subsystem. It just doesn't work that way. The effort that would be required to change the VM subsystem is enourmous. That's why, for instance, NetBSD doesn't have the unified buffer cache/VM working yet (or didn't, last I heard).
Finally, as to code sharing, there just are disagreement as to how some things ought to be done. For instance, NetBSD has opted to go "newconfig" while FreeBSD decided to go "newbus". A lot of concepts _and_ some code for "newbus" came from NetBSD's work, which predated it. But FreeBSD developers had fundamental disagreement as to how this thing should work and, thus, went another way.
***
Final note: I once assumed UVM meant "unified" VM, as in unified VM/buffer cache; I was later told by a NetBSD committer that was not the case, and haven't heard of any news since. If the status quo is no longer that, I'd deeply appreciate if someone more familiar with NetBSD would correct me.
***
PS: yes, there is bad blood between OpenBSD and NetBSD. That's mostly because Theo de Raadt has a love-him-or-hate-him personality. That's just the kind of thing that can't be helped.
Why change to OpenBSD? And, btw, does OpenBSD have jail too?
The one year estimate is for *prototypes*. Now, while people in the computer business have a tendency of confusing prototypes with the final product, that's not the case outside our field.
A prototype in one year looks pretty much a viable estimate. All technologies involved are well known, and it's "just" a matter of combining them.
Bundled.
The plan is not getting users to buy subscriptions. They'll sell this to computer makers, to be bundled with desktops and notebooks. This way, they force the users to either renew or buy Office after one year.
And this won't be a problem for the computer makers, because they won't _have_ any option. First, it will be cheaper, naturally. Second, Microsoft will railroad any opposing makers into accepting it. For instance, by simply not offering the unlimited version at lower prices.
It's brilliant.
/me pats pats his FreeBSD
As opposed to what?
You *wish* the official book was all you need. It isn't. There are scores of topics that are not documented in it and which are _specific_ to FreeBSD, and, thus, not covered by general Unix books (like books on bind, sendmail, *sh, etc).
That's the whole point of the EULA. If you don't do what Microsoft says, they revoke your license.
:-)
I would love to see THAT happens, though.
Yeah! SST sub-orbital combat drops!
Brett Glass has a beef with you? Man, my sentiments...
Not all code in BSD was AT&T's code. After all, it was usually SysV which imported BSD code, not the other way around.
:-)
Though it would be tough finding 8 years code. Only in the most obscure utilities. "yes", maybe.
They have been supported on FreeBSD for a LOOOOONG time. The 3.x's wcd driver had an icky way of supporting it. 4.x's acd driver handles it better.
Oh, come on now, all of you! Almost all new committers are selected simply for the patches they sent. Just check http://www.freebsd.org/support.html#gnats, and count the number of patches submitted by woman, and you'll see it is no "old boys club" that's preventing women from becoming committers.
There are female FreeBSD users, and a good many deal of them are experts in one cs field or another. Why none of them has ever come forth as a committer candidate, if nothing else... beats me.
They can certainly often be found on the secret virtual dens of FreeBSD committers around the net.
1. Become a FreeBSD committer.
This is most easily done by sending enough Problem Reports (see send-pr(1)) that the poor bastards who get to commit all your stuff for you gets tired of it and asks the core team to have brought as a committer.
Committers usually fit in one of the following profiles:
1a. Doc Committers are documentation freaks who go through the handbook, the faq, the web site, the man pages, etc, and actually fix things, add things, etc. There are even the occasional maniacs who track down code hackers and extract, with the help of red hot irons, iron maidens and similar instruments, information required to document a feature.
Suggestion: read freebsd-questions. Make a note of frequently asked questions, and check the answers to it. Write the Q/A to the FAQ. send-pr(1).
1b. Ports committers. These are complete freaks who seems not to have a thing to do in life besides surf the Internet looking for the most arcane pieces of software, and the "port" them to FreeBSD.
Suggestion: look at the software you use that has yet to be part of the FreeBSD ports collection. Read the porters handbook. Follow the instructions in writing the port to FreeBSD (this is often very easy!). send-pr(1).
1c. The code hacker. These are the completely insane persons who go to the trouble of writing code to help the lives of hundreds of thousands or even millions of people around the world, often without getting a single thank you note of recognition. Not only that, but they are often being chased around by docs committers who make use of extremely painful methods to extract information about what they have just written, as if they could remember that! Well, not often enough, actually, but still...
Sugestion: Do you have a problem you need solving, a bug that needs fixing, or a feature you want? Well, write the code for it, and send-pr(1).
2. Become well-known. This is actually easily done. Subscribe and be vocal in -hackers, -current, -stable, -arch and, perhaps a few more choice lists such as -ports, -doc, -scsi, -fs, -mobile, -small, -questions, -chat, -advocacy, besides the ones you'll already find yourself subscribed to, like -committers.
You don't need to be a genius. Listen, present your opinion when an opinion is being asked for, and speak of technical matters when your knowledge enables you to. Never be afraid to ask. Try to avoid flame wars.
3. Candidate yourself to core. This can only be done once every two years, but there is no further requirement aside from being a (active?) committer.
Since you are a woman and there is little female blood around, chances are you'll get elected simply because of gender. Of course, that will happen IF people know you from the mailing lists and commit logs, and you haven't pissed off everyone. But since each committer gets nine votes, I'd wager the chances of them choosing to vote for you just to provide some "balance" is rather large.
1. People wasn't satisfied with the previous core team. No specific reason. Some grudges existed among some committers, but it was more a general feeling of dissatisfaction than anything specific.
2. People wanted to continue to have a core team. People was generally happy with the general organization, so there wasn't any need to a restructuring that would remove the core team altogether. As a matter of fact, most of those who expressed themselves believed that no other project has a better organization.
Thus, it was decided to change the core team. The method people seemed to prefer was elections, and after months of discussions and reviews and votes, this was done.
What more do you want to know?