Modifications I need to make to already BSD licensed code will remain BSD licensed. New pieces of code I write to get it working that are not taken from Sun will be BSD licensed. Everything else will be porting work and will be CDDL.
In the Linux camp, this second idealism is traditionally correct (``Ours, and we want.'') In BSD, this is different. I do feel that I wasn't terribly accurate in my statement as to what I really wanted to convey. Yes, the licensing is going to restrict development. You can't put DTrace in Linux because the GPL and CDDL aren't going to be compatible. But my real point was, if there were no licensing issues, the fragmentation would certainly hinder widespread integration of such a tool that is designed to target ALL aspects of a system.
How my stance on this contradicts any mentality I seem to have conveyed is beyond me. It is important that people are careful with copyrights, but as long as it is clear who owns them and under what terms they are usable, this should never be an issue. I don't want to get into licensing wars, but just throw out that, was the license not an issue, there would be bigger problems.
Only if people are unable to recognize the functionality of DTrace far outweighs licensing issues. Many Linux branches are maintained, and I don't see why somebody couldn't bite the bullet and maintain another Linux branch with DTrace. I think that licensing is secondary. The kernel parts would never be shipped with Linux anyway since they rely on userland tools for functionality, and this is not what Linux is.
No, the real difficulty here is that Linux is by itself only a kernel. Getting this integrated into a full operating system is hard because you have to work with varying userland utilities and make sure that it's integrated properly. I'd expect that somebody would probably do it in Debian, Gentoo, Redhat, or another distribution. In FreeBSD, this is easier, because you are working with an entire system that you know exists and is going to be available for use. You know exactly what will and will not be there.
Integrating it into Linux might thus be a bigger challenge than doing so in FreeBSD (or any other BSD, for that matter). But if somebody were to choose a distribution and JUST GET IT DONE (this is the key), I'm sure others would pick it up.
Well, sure, but for the port you will, since we don't have that sort of privilege assignment and I don't want to initially implement that kind of process accounting.
Yes, I am planning on implementing every provider I can.
While this has been moderated as -1, Troll, it is somewhat true. There have been various performance regressions, which are to be seen in performance tests benchmarking I/O between FreeBSD 4.x and 5.x. Some of the problems are difficult to find and analyze. I'm sorry that this was moderated as a troll, since it is partially a valid point. And DTrace is a great tool to help figure out precisely what is going on.
Quite a lot, actually. I've talked with Eric Schrock about his thesis work, which was implementing some lock analysis tools using DTrace. This allowed him to detect (very precisely) things like LORs, deadlocks, and the like. His thesis is available at http://www.cs.brown.edu/publications/theses/ugrad/ 2003/eschrock.pdf
On 2):
When I've seen demonstrations on this stuff, it has been Bryan Cantrill doing fun stuff with libumem, mdb, and DTrace. I suspect that, at the minimum, we'd need libumem to find and fix this stuff with the accuracy that it can be done in Solaris.
As the guy porting DTrace, I want to clear up a few questions that appear frequently in the comments here. First, though, please be kind to the blog -- it's hosted on our (OffMyServer's) network, which is on a T1. I dunno how bad it got when the story was posted, but just for reference, it'd be nice to not have our network connection die.
FAQ #1 seems to be about the license. Obviously, the CDDL is `viral' in the sense that changes in the code need to be provided under the same terms of the CDDL. In my understanding, this applies only to files in which modifications take place. Extension of something CDDL by adding extra files seems to not require those files to be released under the CDDL. That said, this is a porting effort, and most of the changes I will make will be inside CDDL-licensed files. Thus, anything imported will be under the CDDL. This does not require anything external files to be under the CDDL and thus it can be shipped with FreeBSD without `infecting' other files.
FAQ #2 seems to be whether Sun is happy about this or not. If you have read the article, you would have seen that I've been encouraged to work on this by Sun kernel engineers. Whether Sun as a whole is happy about this is not known to me, but everybody involved in getting it this far has been, so I'm not terribly worried about the rest.
FAQ #3 is about performance incurrences. Certain aspects of DTrace incur performance penalties, but only when DTrace is running. DTrace by itself is a library and a userland tool. All instrumentation is done dynamically and when DTrace is not instrumenting something, no performance hits happen whatsoever. When it is running, we have several advantages to other tools because (unlike e.g. truss) we are instrumenting single processes. Processes which are not being instrumented will not take any performance hits other than the fact that they have a bit less CPU usage since DTrace is instrumenting something.
How do you not take a performance penalty when the profiler is off? You must be root to run DTrace. When you instrument functions inside an application, this is done on-the-fly by rewriting the code that is being executed. When it is not being executed, nothing is being rewritten and it's not even looking to rewrite something. It's just some code resident in memory (in fact, modules are even loaded as needed). It sounds like it might be prone to security flaws, but keep in mind that this has been working in production for a while now.
When will this be in Linux? I don't know. I won't be working on it. I challenge _you_ to do this:)
Is this vaporware? No. I'm continuing development from about a week off (since I lost my development machine) this evening.
Feel free to ask more questions, I'll try to address them as I see them. But please refrain from bad-mouthing Sun or myself out of spite, jealousy, or whatever. I know it's fun to troll (if you're a troll), but the rest of us really don't appreciate it.
This seems quite similar to the concept of Inferno (http://www.vitanuova.com/ from Vita Nuova Limited, except Inferno runs hosted on the operating system (it can run natively). Similar concept, different implementation. I'll stick with Plan 9, though:)
Bullshit. People don't use plan 9 for a variety of reasons, and the license is not one of them. Some reasons why:
Plan 9 is not advertised in thousands of magazines, websites, movies, tv shows, etc.
Plan 9 is not UNIX and it's not very UNIX-like either. If you're familiar with UNIX concepts, you'll probably have to ditch most of them to figure out how Plan 9 works.
The Web is not Plan 9 compatible.
Plan 9 isn't made for everyday desktop use, ``surfing the net'' or really most things that you/.ers do.
People are adverse to the UI.
People try to change Plan 9 and do not like the adverse reactions they get from the user base.
People try to change Plan 9 and get lost without a standard C library.
People try to change Plan 9 and then it's not Plan 9 anymore.
I can keep going, but I think this covers some of the larger reasons. Who cares about the license?
And some of us just posted constructive criticism and told you how you could have improved your experience with DragonFly, could have written a better review, and gave suggestions for future articles. You can hold this grudge against all of the users / developers of DragonFly, but you're the one who will end up looking like a lunatic.
I for one, never did or said anything adverse, and you still call me an asshole and lunatic, simply because I use and develop DragonFly BSD.
Good for Linux. We aren't Linux, neither do we aim to be. We're BSD and by nature provide a complete OS, not just a kernel. We'll be implementing our own SSI stuff and we won't be taking any of it from Linux, of course. When our SSI work is done, we'll be able to do that too.
What's the big deal though? Who says because Linux already can do it, that it's pointless for us to implement it as well?
Hehe, okay. I guess I simply misunderstood the type of information you were looking for, so forgive what others apparently have called my ``hotheadedness.''
As has been explained a gazillion times, DragonFly is a fork of the FreeBSD, which started with the FreeBSD 4.8-RELEASE code.
The kernel features listed in the original post attempt to utilize features of modern processors and take into account modern ideas and research when developing new features.
One could say that our focus is on performance. A lot of the work that Matt, Hiten, Joerg and Jeffery Hsu are doing involve cranking up performance. This isn't to say that we aren't worried about stability or security, though.
The ``apparent misguided path of FreeBSD-5'' is a long political story and is one which I really don't like to get into much (because each side can be stressed and turned into a war), but basically Matt Dillon thought that the way the FreeBSD 5 series was handling SMP was irrational. His main reasons were that:
a) A mutex system would clutter up the kernel with tons of locks and obfuscate the code, effectively requiring experts in the area to continue further development,
b) Future developers would have to make sure that they understand how the mutex API works so that they don't stumble into weird SMP problems later,
c) It's heavyweight and isn't as fast as it could be.
Our model also opens up the future for really neat things like SSI (single system image), which shouldn't be terribly hard to implement. Our TODO list is large, and it's going to take a while, but I think we all enjoy working together on the project. It's a nice friendly community. Come check it out sometime:)
He didn't ask for support. He failed to read the features that were listed in the article, all of which are well explained on DragonFly BSD's site. If you have specific questions about what one feature offers over another, I'm certainly fine answering this (and, for the record, don't mean to come over with an elitist attitude), but really: if I said, ``Why should I choose Debian over SuSE'', I'm sure I'd get a million references to the websites of both products.
Granted, the differences between the BSDs are of a different nature than those of different Linux distributions, but I think my point was rather clear.
And really, the post itself lists a TON of features DragonFly has. I'm not going to list them all again.
Not only did you not read anything in the links in the/. post, you appear to have not even read the post. Go do this. In short, we're about performance.
Secondly, you appear to be looking for a reason that we are ``superior'' to any other BSD variant. When you find clear reasons why one operating system is superior over another for any given application, please let me know.
Our developer community is rather small; and we have an active IRC community of about 40 people (which includes a good number of our developers). We generally keep in touch this way, and of course, through the mailing lists.
Anyway, I'll speak for myself here: If I've ever needed a project to work on, I've found the DragonFly community to be the most responsive and helpful community in both finding and completing a project. And from the lists, I see that many people do actually contribute patches and we do have a large community of ``lurkers'' as it were.
I sure hope you're not syncing with -STABLE for the *cough* stability.
http://www.freebsd.org/handbook/current-stable.h tm l, just like I post in every Slashdot thread about FreeBSD where all the kids start raving about their rock-solid -STABLE boxes.
Well, I hate to crash everyone's party, but take a look at:
http://www.openbsd.org/security.html#34
When you're talking about remote exploits, OpenBSD might rate well by default. When you're talking about exploits in general, OpenBSD has just as many / more than the rest.
Slashdot Mirror
I think that what will end up happening is this:
Modifications I need to make to already BSD licensed code will remain BSD licensed. New pieces of code I write to get it working that are not taken from Sun will be BSD licensed. Everything else will be porting work and will be CDDL.
In the Linux camp, this second idealism is traditionally correct (``Ours, and we want.'') In BSD, this is different. I do feel that I wasn't terribly accurate in my statement as to what I really wanted to convey. Yes, the licensing is going to restrict development. You can't put DTrace in Linux because the GPL and CDDL aren't going to be compatible. But my real point was, if there were no licensing issues, the fragmentation would certainly hinder widespread integration of such a tool that is designed to target ALL aspects of a system.
How my stance on this contradicts any mentality I seem to have conveyed is beyond me. It is important that people are careful with copyrights, but as long as it is clear who owns them and under what terms they are usable, this should never be an issue. I don't want to get into licensing wars, but just throw out that, was the license not an issue, there would be bigger problems.
Only if people are unable to recognize the functionality of DTrace far outweighs licensing issues. Many Linux branches are maintained, and I don't see why somebody couldn't bite the bullet and maintain another Linux branch with DTrace. I think that licensing is secondary. The kernel parts would never be shipped with Linux anyway since they rely on userland tools for functionality, and this is not what Linux is.
No, the real difficulty here is that Linux is by itself only a kernel. Getting this integrated into a full operating system is hard because you have to work with varying userland utilities and make sure that it's integrated properly. I'd expect that somebody would probably do it in Debian, Gentoo, Redhat, or another distribution. In FreeBSD, this is easier, because you are working with an entire system that you know exists and is going to be available for use. You know exactly what will and will not be there.
Integrating it into Linux might thus be a bigger challenge than doing so in FreeBSD (or any other BSD, for that matter). But if somebody were to choose a distribution and JUST GET IT DONE (this is the key), I'm sure others would pick it up.
Well, sure, but for the port you will, since we don't have that sort of privilege assignment and I don't want to initially implement that kind of process accounting.
Yes, I am planning on implementing every provider I can.
While this has been moderated as -1, Troll, it is somewhat true. There have been various performance regressions, which are to be seen in performance tests benchmarking I/O between FreeBSD 4.x and 5.x. Some of the problems are difficult to find and analyze. I'm sorry that this was moderated as a troll, since it is partially a valid point. And DTrace is a great tool to help figure out precisely what is going on.
On 1):
/ 2003/eschrock.pdf
Quite a lot, actually. I've talked with Eric Schrock about his thesis work, which was implementing some lock analysis tools using DTrace. This allowed him to detect (very precisely) things like LORs, deadlocks, and the like. His thesis is available at http://www.cs.brown.edu/publications/theses/ugrad
On 2):
When I've seen demonstrations on this stuff, it has been Bryan Cantrill doing fun stuff with libumem, mdb, and DTrace. I suspect that, at the minimum, we'd need libumem to find and fix this stuff with the accuracy that it can be done in Solaris.
Hope this is useful information.
--Devon
As the guy porting DTrace, I want to clear up a few questions that appear frequently in the comments here. First, though, please be kind to the blog -- it's hosted on our (OffMyServer's) network, which is on a T1. I dunno how bad it got when the story was posted, but just for reference, it'd be nice to not have our network connection die.
:)
FAQ #1 seems to be about the license. Obviously, the CDDL is `viral' in the sense that changes in the code need to be provided under the same terms of the CDDL. In my understanding, this applies only to files in which modifications take place. Extension of something CDDL by adding extra files seems to not require those files to be released under the CDDL. That said, this is a porting effort, and most of the changes I will make will be inside CDDL-licensed files. Thus, anything imported will be under the CDDL. This does not require anything external files to be under the CDDL and thus it can be shipped with FreeBSD without `infecting' other files.
FAQ #2 seems to be whether Sun is happy about this or not. If you have read the article, you would have seen that I've been encouraged to work on this by Sun kernel engineers. Whether Sun as a whole is happy about this is not known to me, but everybody involved in getting it this far has been, so I'm not terribly worried about the rest.
FAQ #3 is about performance incurrences. Certain aspects of DTrace incur performance penalties, but only when DTrace is running. DTrace by itself is a library and a userland tool. All instrumentation is done dynamically and when DTrace is not instrumenting something, no performance hits happen whatsoever. When it is running, we have several advantages to other tools because (unlike e.g. truss) we are instrumenting single processes. Processes which are not being instrumented will not take any performance hits other than the fact that they have a bit less CPU usage since DTrace is instrumenting something.
How do you not take a performance penalty when the profiler is off? You must be root to run DTrace. When you instrument functions inside an application, this is done on-the-fly by rewriting the code that is being executed. When it is not being executed, nothing is being rewritten and it's not even looking to rewrite something. It's just some code resident in memory (in fact, modules are even loaded as needed). It sounds like it might be prone to security flaws, but keep in mind that this has been working in production for a while now.
When will this be in Linux? I don't know. I won't be working on it. I challenge _you_ to do this
Is this vaporware? No. I'm continuing development from about a week off (since I lost my development machine) this evening.
Feel free to ask more questions, I'll try to address them as I see them. But please refrain from bad-mouthing Sun or myself out of spite, jealousy, or whatever. I know it's fun to troll (if you're a troll), but the rest of us really don't appreciate it.
--Devon
This seems quite similar to the concept of Inferno (http://www.vitanuova.com/ from Vita Nuova Limited, except Inferno runs hosted on the operating system (it can run natively). Similar concept, different implementation. I'll stick with Plan 9, though :)
Bullshit. People don't use plan 9 for a variety of reasons, and the license is not one of them. Some reasons why:
/.ers do.
Plan 9 is not advertised in thousands of magazines, websites, movies, tv shows, etc.
Plan 9 is not UNIX and it's not very UNIX-like either. If you're familiar with UNIX concepts, you'll probably have to ditch most of them to figure out how Plan 9 works.
The Web is not Plan 9 compatible.
Plan 9 isn't made for everyday desktop use, ``surfing the net'' or really most things that you
People are adverse to the UI.
People try to change Plan 9 and do not like the adverse reactions they get from the user base.
People try to change Plan 9 and get lost without a standard C library.
People try to change Plan 9 and then it's not Plan 9 anymore.
I can keep going, but I think this covers some of the larger reasons. Who cares about the license?
And some of us just posted constructive criticism and told you how you could have improved your experience with DragonFly, could have written a better review, and gave suggestions for future articles. You can hold this grudge against all of the users / developers of DragonFly, but you're the one who will end up looking like a lunatic.
I for one, never did or said anything adverse, and you still call me an asshole and lunatic, simply because I use and develop DragonFly BSD.
*claps hands* Great logic!
Nope. The one in the second post. Hence above.
Good for Linux. We aren't Linux, neither do we aim to be. We're BSD and by nature provide a complete OS, not just a kernel. We'll be implementing our own SSI stuff and we won't be taking any of it from Linux, of course. When our SSI work is done, we'll be able to do that too.
What's the big deal though? Who says because Linux already can do it, that it's pointless for us to implement it as well?
*shrug*
Hehe, okay. I guess I simply misunderstood the type of information you were looking for, so forgive what others apparently have called my ``hotheadedness.''
:)
As has been explained a gazillion times, DragonFly is a fork of the FreeBSD, which started with the FreeBSD 4.8-RELEASE code.
The kernel features listed in the original post attempt to utilize features of modern processors and take into account modern ideas and research when developing new features.
One could say that our focus is on performance. A lot of the work that Matt, Hiten, Joerg and Jeffery Hsu are doing involve cranking up performance. This isn't to say that we aren't worried about stability or security, though.
The ``apparent misguided path of FreeBSD-5'' is a long political story and is one which I really don't like to get into much (because each side can be stressed and turned into a war), but basically Matt Dillon thought that the way the FreeBSD 5 series was handling SMP was irrational. His main reasons were that:
a) A mutex system would clutter up the kernel with tons of locks and obfuscate the code, effectively requiring experts in the area to continue further development,
b) Future developers would have to make sure that they understand how the mutex API works so that they don't stumble into weird SMP problems later,
c) It's heavyweight and isn't as fast as it could be.
Our model also opens up the future for really neat things like SSI (single system image), which shouldn't be terribly hard to implement. Our TODO list is large, and it's going to take a while, but I think we all enjoy working together on the project. It's a nice friendly community. Come check it out sometime
And, as stated BEFORE I said that, there's a clear and concise list at dragonflybsd.org. What more do you want?
He didn't ask for support. He failed to read the features that were listed in the article, all of which are well explained on DragonFly BSD's site. If you have specific questions about what one feature offers over another, I'm certainly fine answering this (and, for the record, don't mean to come over with an elitist attitude), but really: if I said, ``Why should I choose Debian over SuSE'', I'm sure I'd get a million references to the websites of both products.
Granted, the differences between the BSDs are of a different nature than those of different Linux distributions, but I think my point was rather clear.
And really, the post itself lists a TON of features DragonFly has. I'm not going to list them all again.
Not only did you not read anything in the links in the /. post, you appear to have not even read the post. Go do this. In short, we're about performance.
Secondly, you appear to be looking for a reason that we are ``superior'' to any other BSD variant. When you find clear reasons why one operating system is superior over another for any given application, please let me know.
Hey, I don't own the-bofh.org for nothing :-D
Our developer community is rather small; and we have an active IRC community of about 40 people (which includes a good number of our developers). We generally keep in touch this way, and of course, through the mailing lists.
Anyway, I'll speak for myself here: If I've ever needed a project to work on, I've found the DragonFly community to be the most responsive and helpful community in both finding and completing a project. And from the lists, I see that many people do actually contribute patches and we do have a large community of ``lurkers'' as it were.
hernan43: Michigan, 100Mbit
JustinS: 100Mbit, Rochester NY
I know it's a troll but BSDi didn't die. We sold BSD/OS to Wind River and continued as iXsystems / Offmyserver.
Or you could just click on the link I posted above which obsoletes your list every time someone wakes up in #DragonFlyBSD :-D
Additionally, a torrent and list of mirrors are also available.
I sure hope you're not syncing with -STABLE for the *cough* stability.
h tm l, just like I post in every Slashdot thread about FreeBSD where all the kids start raving about their rock-solid -STABLE boxes.
http://www.freebsd.org/handbook/current-stable.
Well, I hate to crash everyone's party, but take a look at:
http://www.openbsd.org/security.html#34
When you're talking about remote exploits, OpenBSD might rate well by default. When you're talking about exploits in general, OpenBSD has just as many / more than the rest.
SCO has the power to direct their DNS anywhere. Why don't they save the Internet a lot of bandwidth and do
www.sco.com IN A 127.0.0.1
Case closed.