Forgot your password?
typodupeerror
Sun Microsystems Operating Systems BSD IT

Solaris DTrace To Be Ported to FreeBSD 151

Posted by Zonk
from the new-toys dept.
daria42 writes "It looks like Sun's famous Dynamic Tracing tool - one of the best features in Solaris 10 - is getting ported to FreeBSD. Sun open-sourced the code back in January and it has been picked up by FreeBSD developer Devon O'Dell. The tool provides insanely great advanced performance analysis and debugging features for server software. Good to see some result come out of the Sun open-sourcing process." From the article: "O'Dell told ZDNet Australia the aim of the project -- which commenced a month ago -- was that all scripts and applications that utilised DTrace under its native Solaris environment should be able to run in FreeBSD with no changes. While FreeBSD's existing ktrace function was similar to DTrace, it was limited in scope, according to O'Dell. 'FreeBSD implements a somewhat similar facility for dynamically instrumenting syscalls for any given application,' he said."
This discussion has been archived. No new comments can be posted.

Solaris DTrace To Be Ported to FreeBSD

Comments Filter:
  • License? (Score:3, Interesting)

    by rpbailey1642 (766298) <robert DOT b DOT pratt AT gmail DOT com> on Thursday September 08, 2005 @09:41AM (#13508768)
    The article doesn't say whether the program will be released under the BSD license (unlikely) or whether it will remain under the CDDL [opensource.org]. The latter seems most likely.
  • Good for Ruby! (Score:5, Insightful)

    by fishdan (569872) * on Thursday September 08, 2005 @09:41AM (#13508772) Homepage Journal
    OOOH! Someone please tell me that the OSX port is close behind. I'd been living on a mac for quite a while, but after seeing the how dtrace can help with Ruby dev [sun.com] I'd switched to Solaris for my Ruby optimization (which is up to about 30% of my work now). If I can start doing this on my powerbook, I'll be a super happy camper.

    I'm not sure how this benefits Sun, but something as awesome as this, I'm willing to assume it's altruism, and I appreciate it.

    • Re:Good for Ruby! (Score:5, Informative)

      by TheTomcat (53158) on Thursday September 08, 2005 @10:21AM (#13509119) Homepage
      There have been bindings for PHP [php.net] for a few days, now [netevil.org].

      S

    • Re:Good for Ruby! (Score:5, Insightful)

      by jm91509 (161085) on Thursday September 08, 2005 @11:12AM (#13509574) Homepage
      I'm not sure how this benefits Sun, but something as awesome as this, I'm willing to assume it's altruism, and I appreciate it.

      Thats easy. You used to be a Mac only person (making some guesses here...) but now you are a Solaris user.

      How many other people are trying solaris for the first time because of this feature?

      Suck in the developers and they may turn into server sales or even just positive PR.

      Sounds like more than altruisim to me.
      • Re:Good for Ruby! (Score:3, Interesting)

        by evilviper (135110) on Thursday September 08, 2005 @11:07PM (#13515441) Journal
        You used to be a Mac only person (making some guesses here...) but now you are a Solaris user.

        No, I think he's talking about Sun making dtrace open source, which might turn him into a FreeBSD user, or perhaps allow him to use OS X exclusively (not likely with the kernel changes needed, but maybe Apple will see the light.)

        So, sacrificing your value-added product to the public domain seems to be entirely altruistic AFAICT. With something like NFS, they stood to gain directly by allowing others to use it, but that doesn't appear to be the case with dtrace.

        Perhaps it's not altruism. Perhaps it's an attempt to improve all Unix systems, to get people to switch away from Windows. That would be very benefitial to Sun.
    • by mccalli (323026) on Thursday September 08, 2005 @11:15AM (#13509596) Homepage
      Someone please tell me that the OSX port is close behind.

      I'd hope so too, but doesn't it depend on the kernel? OS X doesn't have a FreeBSD kernel, it's a MACH-based affair.

      It clearly can be ported between kernels because this is precisely what the article is describing. However, that doesn't translate to the work actually taking place to run it against MACH.

      Cheers,
      Ian

    • Re:Good for Ruby! (Score:2, Interesting)

      by laffer1 (701823) <luke@ f o o l i s h g a m es.com> on Thursday September 08, 2005 @05:59PM (#13513505) Homepage Journal
      Well the kernel's are different as someone else pointed out, but there is a powerpc port of FreeBSD in the works. That means you can dual boot your Mac with FreeBSD and OS X. It would be easier than switching to Sun since you don't have to buy new hardware.

      I should point out that the PowerPC port is not tier 1 yet so its not perfect. I know there have been a few problems with X11 and keyboards on laptops that use ADB protocol are broken (all ibooks for example) I think some powerbook models use USB so you might be ok there.

      There is a freebsd-ppc mailing list. If you look at the archives you can learn more about it. They just released an iso of 6.0 beta 3 or 4 for it. :)
  • by UltimaGuy (745333) on Thursday September 08, 2005 @09:41AM (#13508776) Homepage
    I have seen the use of this tool, and seriously, it rocks. There is no other tracing tool to compare with this. So, I am very eager to hear any news about this being ported to Linux, as not many people use FreeBSD ;-)
    • by brilinux (255400) <kg4qxk.arrl@net> on Thursday September 08, 2005 @09:50AM (#13508853) Homepage Journal
      Um, actually, quite a few people (myself included) use it on servers (and I use it on my laptop as well), and most of us are quite happy about this, and get quite upset when people blow us off as if the only real F/OS OS to use is GNU/Linux. You might actually like a BSD if you try it...
      • by 10Ghz (453478) on Thursday September 08, 2005 @09:59AM (#13508944)
        Well, there WAS a smiley in the GP-post, in case you missed it...
      • by misleb (129952) on Thursday September 08, 2005 @01:38PM (#13510924)
        I've been using Linux for almost a decade now. I've settled on the distribution that I prefer (Debian). But I recently started a new sysadmin job where they run mostly FSBD web/mail servers. I had a chance to build a new mail gateway. I resisted the temptation to just go with what I was comfortable with (Debian) and I installed FBSD.

        My first impression is that FBSD is like another distribution of Linux. I don't mean pigeonhole FBSD. And I realize it may come as an insult, but after using so many different flavors of Linux, that is what the differences amount to as far as I am concerned. And looking at it as a distribution of Linux, it isn't all that impressive. I dont' particularly care to compile most software from source. Although the ports system does offer some very up to date packages (if you cvsup), if I wanted to to compile everything from source and have bleeding edge versions of stuff, I'd just run Gentoo Linux. The Gentoo portage system is much more refined than the old, clunky BSD ports system. Overall, Debian's packaging system beats all, hands down, IMO.

        On a server it isn't such a big deal to compile everything from source because generally you install it and let it run for months or years with only minor updates. But on a workstation it is downright annoying.

        Is there any reason why I shouldn't look at FBSD as if it were a flavor of Linux? Yeah, it has a different kernel. I guess FBSD might be a little faster? That is what the benchmarks say, but the difference isn't staggering. I certainly don't notice. Is it more stable? I haven't had many problems with Linux that couldn't be blamed on cheap PC hardware.

        Anyway, I'll continue using FBSD where I work if only because there is no compelling reason NOT to use it. I probably could convert it all to Linux if I really wanted to.

        -matthew
        • by halber_mensch (851834) on Thursday September 08, 2005 @02:58PM (#13511885)

          Is there any reason why I shouldn't look at FBSD as if it were a flavor of Linux? Yeah, it has a different kernel. I guess FBSD might be a little faster? That is what the benchmarks say, but the difference isn't staggering. I certainly don't notice. Is it more stable? I haven't had many problems with Linux that couldn't be blamed on cheap PC hardware.

          Yes, a very important reason - FreeBSD is not Linux, just as surely as SCO UnixWare is not Solaris. Their codebase is certainly not the same, and in fact FreeBSD's code lineage dates back many years before Linux.

          FreeBSD and Linux, being F/OSS systems, share a very large base of F/OSS software, so looking at kde on X on FreeBSD really won't appear that different from looking at kde on X on linux. I could just as well ask why anyone would want to use Linux when it just looks like a derivative of FreeBSD, which predates it. but that would not be a fair assessment because Linux is a seperate work built by another party. Yes, it is a unix-like system. Yes, it strives to adhere to POSIX standards. Yes, it runs all the same software. But no, it is a different system.

          I have been using FreeBSD and NetBSD for many years, and where I work all of our stuff is on SuSE. In my opinion, SuSE is impossible to upgrade, its package system is inadequate, and shorewall is a lousy attempt at ip filtering. If I had my way I'd probably replace everything with FreeBSD. But did you notice somehting about the attitude of my opinions? Wasn't your first thought "Well gee, you use FreeBSD all the time and you've probably barely given SuSE Linux a shot?" If it was, you would be right. Because I learned to accomplish tasks in FreeBSD, I favor it - the same way I favor speaking in english over german because english is my native language. I'm sure if you sit down and think about it, when you picked up FreeBSD you tried to do things in the Debian idiom, expecting Debian results. But you didn't get them. So you're underwhelmed. It's natural, but please don't try to attribute it to FreeBSD being an inadequate copy of your favorite system, because that simply is a lie.

          On the packages/ports system, I think you've really overdramaticized your plight with the BSD way-of-doing-things. First, you can cvsup the ports tree and compile from source. But you can also use pkg_add to add binary packages. If you don't want to fetch the package tarball yourself, you can use pkg_add's remote fetching feature. Simply pkg_add -r and you're on your way. It will take care of dependencies and the package database will record the package's information. You can also install portupgrade and use it to magically update a port and its dependencies when it is time to upgrade. It's not a difficult or time consuming system to use. I'm unfamiliar with Debian's package system, so I can't make any comments on it, but FreeBSD's package system has always been very useful fo me, and it gets more powerful all the time.

          Overall, though, Linux and BSD really do feed from eachother's growth. What's good for one is good for the other. I may use FreeBSD, but that doesn't mean Linux is useless; and the opposite is true as well. All this bickering is really pointless because both projects will continue on in their own directions; some people will favor the one while some people will favor the other. It's simply a matter of preference

          • by T.Hobbes (101603) on Thursday September 08, 2005 @09:31PM (#13514880)
            How does it work? That's some seriously obfuscated code!
            • by halber_mensch (851834) on Friday September 09, 2005 @01:49PM (#13520471)
              :) I was hoping someone would comment on that one day. I'm not too well known for keeping secrets, so I'll let the cat out of the bag. I was inspired by another slashdot user (I forgot who it is) who used a similar piece of ruby code that just sort of magically worked. The idea in that code was to obfuscate a piece of text by 'unpacking' it from ascii string to another data format, and magically re-extracting it in a print command by packing it again.

              I took this to another level and not only 'unpacked' the text, but the entire perl command for printing the 'unpacked' string as well. Thus perl is ordered to evaluate the statement hidden in the 'unpacked' hexadecimal string, which is 'packed' to reveal a valid perl statement.

              I made a perl script to generate the (weakly) obfuscated command. Please keep in mind I am a C programmer by nature and that my approach to Perl is very indicative of that fact:
              #!/usr/bin/env perl
              die "you must supply one argument.\n" if($#ARGV != 0);
              my $ephrase;
              my $dephrase;
              $ephrase = unpack(q/H*/ , $ARGV[0]);
              $dephrase = unpack(q/H*/, q/print pack(q{H*},q{/ . "$ephrase" . q/});/);
              print qq/perl -e "eval pack(q{H*}, join q{},qw{$dephrase})"\n/;
    • by tsalaroth (798327) <tsal@arikel.net> on Thursday September 08, 2005 @10:01AM (#13508958) Homepage Journal
      I'd be willing to bet there's a shitload of FreeBSD web servers out there, since I manage twelve of them, myself.

      Linux has its uses and is great for many tasks, but only Gentoo comes close to the ports system and how well it manages software installation.

      Either way, I'm hoping that yes, it will be ported to Linux as well, if it hasn't been already.
      • by speculatrix (678524) on Thursday September 08, 2005 @12:52PM (#13510476)
        FreeBSD... linux great but... only Gentoo comes close to the ports system

        I've used many different package systems - solaris's, linux (debian's apt, suse's yast, redhat's), ipkg on zaurus... and maybe I'm missing something, but I didn't find FreeBSD's ports better than debian's system, or even much better than yast's... and it wasn't entirely unbreakable either.

        I'm sorry, FreeBSD guys, but it's still too much of a minority interest, with too many real-world solutions missing.

      • by OrangeTide (124937) on Thursday September 08, 2005 @12:55PM (#13510498) Homepage Journal
        Actually crux [crux.nu] is closer to ports, and slackware + pkg-src [netbsd.org] is basically the same thing.
      • by jonabbey (2498) * <jonabbey@ganymeta.org> on Thursday September 08, 2005 @04:56PM (#13512951) Homepage

        I've heard such paeans to the FreeBSD ports system for years, but when I actually spent time working with it, I found it a big pain.

        First, ports can only really handle installation of software packages under one's /usr/local tree. It doesn't do anything for upgrading other pieces of the file system.

        Second, the whole thing isn't very user friendly. I spent a week or so developing a new port, that involved dependencies on a dozen or so other ports. Every time I tried doing a 'make package', it went through all of the dependencies and did a 'make install' on them, which did me exactly 0 good, as I wanted them in package format for installation on another system. I had to write a script to analyze the dependency tree manually, and then go back and run a 'make package' in each of those ports.. after running 'make uninstall' so that it would allow me to do so. Which came into conflict with other ports and packages.. yuck.

        RPM is a bazillion times cleaner than that. And much better documented.

        Now, granted, there are some very nice things about the FreeBSD system. The use of /usr/local/etc/rc.conf to configure all major subsystems in one place is very nice, and the ability to provide Make variable definitions to semi-globally adjust options like X dependency or no on packages is nice as well. The incredibly fine level of granularity for things like Emacs elisp files and CPAN modules must make some people happy as well, though I find it more of a hindrance than a help (particularly with the aforementioned build issues).

        All in all, the limited niceties don't seem to counterbalance the limited power of the system to handle anything other than strictly defined pieces of /usr/local.

        That's even setting aside the lack of support for doing in-place upgrades.

        I just don't see the appeal.

    • by Anonymous Coward on Thursday September 08, 2005 @10:08AM (#13509012)

      There is no other tracing tool to compare with this.

      Yes, there is: SystemTap [redhat.com] by Red Hat, IBM and Intel.

    • by Zedrick (764028) on Thursday September 08, 2005 @10:32AM (#13509200)
      as not many people use FreeBSD ;-)

      ...and that's their loss. I think that 75% of those who give FreeBSD a (serious) try will stick to it. It's the best thing since Amiga OS, and I'm happy to run it both on my desktop, and for my router+web/ftp-server in the wardrobe.
      • by Short Circuit (52384) * <mikemol@gmail.com> on Thursday September 08, 2005 @10:58AM (#13509445) Homepage Journal
        I've been spoiled by GNU extensions to tools like grep and ls. Considering I spend most of my time in a command line (under a GNOME terminal, no less), I'd probably find myself frequently irritated.

        That said, I have downloaded the FreesBIE LiveCD; I just haven't burned it yet.
        • by Electrum (94638) <david@acz.org> on Thursday September 08, 2005 @11:35AM (#13509782) Homepage
          I've been spoiled by GNU extensions to tools like grep and ls. Considering I spend most of my time in a command line (under a GNOME terminal, no less), I'd probably find myself frequently irritated.

          Install the sysutils/coreutils [freshports.org] port. You'll get all the GNU utilities with a 'g' prefix, i.e. gls, gcp, etc. You can alias the ones you want to use.
        • by Some Random Username (873177) on Thursday September 08, 2005 @01:18PM (#13510708) Journal
          Extensions like what? I spend lots of time at a command line too, and that's why I can't stand linux machines, the GNU tools are awful compared to the BSD ones. I'd really be interested in hearing what is "missing" from the BSDs grep and ls, besides ls displaying everything in color.
    • by diegocgteleline.es (653730) on Thursday September 08, 2005 @10:34AM (#13509218)
      Linux does have a "comparable" feature (soon to be merged in mainline) called "kprobes", or "systemtap" (systemtap uses kprobes)

      You can see a fairly detailed analisis in the 2005 Proceedings, Volume 2, page 57 [linuxsymposium.org] of the linux symposium

      Also some doc from IBM: http://www-128.ibm.com/developerworks/linux/librar y/l-kprobes.html [ibm.com]

      also there's a "linux trace toolkit". A post about LTT vs dtrace [theaimsgroup.com]...whatever, too much flamewar for my taste.
      • by Anonymous Coward on Thursday September 08, 2005 @11:13AM (#13509583)
        kprobes is not comparable to dtrace, to see a comparison between dtrace and kprobes check out
        dtrace vs. krpobes [blogspot.com]

        systemtap is in its infancy and being designed without safety as a priority, dtrace was created to be 100% safe to run anytime, even in production. systemtap is being made for the kernel hacker to debug the kernel. With possibly some userland probes and safety as an after thought. Sure they talk about safety as a goal. But as documented dtrace_usenix.pdf [sun.com]
        dtrace was created from the start to be safe and secure. They even sacrafice some functionality to keep production servers safe. Systemtap is like building a bank they build the building, bring in the money, and desks, and machines, and promise that top of the line doors, windows and safe will top of the line and installed any day now.
      • by TheRaven64 (641858) on Thursday September 08, 2005 @11:21AM (#13509641) Journal
        I went to a talk by an IBM guy on systemtap at Linux 2005. A few people in the audience asked how it was different / better than DTrace. As far as I could tell, the answer was `We're IBM! And we made it! And we're better than Sun! Sun suck!' I have never seen quite so much evasion of a question outside of a political rally.
        • by Anonymous Coward on Thursday September 08, 2005 @12:15PM (#13510130)
          I was there too and that was most certainly NOT the reaction IBM gave. There were some Sun guys in the audience that kept harping on the lack of equivalence to dtrace, and the IBM guys repeated again and again that systemtap was in its early stages of development. Apparently it wasn't good enough for the Sun guys in the audience who basically heckelled the presenters throughout. Pretty damned shameful behavior I have to say.
    • by JabrTheHut (640719) on Thursday September 08, 2005 @12:26PM (#13510216)
      As soon as enough people in the Linux community, including Linus, can eat humble pie, admit they were wrong, and start working on it. I believe Linus called it a joke. Shame it was on him...
  • by ReformedExCon (897248) <reformed.excon@gmail.com> on Thursday September 08, 2005 @09:43AM (#13508796)
    It looks like a really useful tool. I wonder what the performance penalty is when the tool is turned off.

    Do you need to instrument the calls you expect to profile? If so, how can you avoid taking that performance hit when deciding whether to perform the profiling or not, even when the profiler is off? It's still got to check the profiler level each time, doesn't it?
  • by Anonymous Coward on Thursday September 08, 2005 @09:44AM (#13508798)
    This has been working on Linux sometime in 2004

    The official reason is that it wasn't release was because Linus didn't want the BSD folks using it, but the real reason is the Department of Homeland security didn't want the BSD folk to find the last bug in their release.

    Thats what I just head right now. (Thanks, voices)
    • by Hackeron (704093) on Thursday September 08, 2005 @10:12AM (#13509048) Journal
      if you're referring to http://oprofile.sourceforge.net/news/ [sourceforge.net], you're sadly mistaken. Realtime system profiling is very far behind on Linux compared to Solaris.

      Can you monitor how much network bandwidth each process uses? -- Sure you can see listening ports and IP traffic, and ntop is fantastic at showing what network bandwidth is used for (i.e. spotting p2p and IM traffic, eg). However if you have a trojen and you see suspecious network activity, there is a certain amount of guess work to try to find the process. Solaris will show exactly what process is making what connection where and the bandwidth it is using.

      Can you monitor how much IO utilization each process has? -- No, only IO wait and CPU consumption which is normally enough, but say you have a script thats just reading all content on the disk and redirects it to /dev/null - Sure you'll see abount 1% cpu utilization, but again, guess work at whats actually using IO.

      Sure you're usually right making an educated guess but system profiling is far ahead on Solaris.
  • Wikipedia:DTrace (Score:5, Informative)

    by Saiyine (689367) on Thursday September 08, 2005 @09:54AM (#13508901) Homepage

    For we that don't have a clue what DTrace is, here's what the [wikipedia.org] has to say: DTrace allows to do performance tuning with applications and troubleshoot production systems--all with little or no performance impact. DTrace provides improved visibility into kernel and application activity, giving the user operational insights with which they can make performance gains..

    The no performance penalty sounds really cool to me.

    --
    Superb hosting [dreamhost.com] 4800MB Storage, 120GB bandwidth, $7,95.
    Picaday! [picaday.host.sk] Soon to be open "Picture of the day web".
    • by Willy on Wheels (889645) on Thursday September 08, 2005 @10:35AM (#13509233) Homepage Journal
      The article is a stub at the moment. Lets put the slashdot effect into good use and expand it [wikipedia.org]
    • by Tony Hoyle (11698) <tmh@nodomain.org> on Thursday September 08, 2005 @10:45AM (#13509319) Homepage
      So how does it differ from truss, or even ltrace/strace? Not much detail there... just marketing blurb ('operational insights??').

      It's not on solaris 9, just checked (checked solaris 8 for fun too), so can't make any real comparisons.. anything that makes solaris debugging less than a total 'mare sounds like a good idea though.

      (shouldn't be too hard on solaris though... I have to do an HPUX port too - that's an OS I wouldn't wish on my worst enemy...)
      • Re:Wikipedia:DTrace (Score:4, Informative)

        by davecb (6526) * <davec-b@rogers.com> on Thursday September 08, 2005 @10:53AM (#13509402) Homepage Journal
        It's way more fine-grained than truss or apptrace (which I helped build), and has overhead only when used.

        --dave

        • by popechunk (863629) on Thursday September 08, 2005 @12:39PM (#13510342) Journal
          I know that there are not a ton of Solaris SAs on /. (compared to Linux/MS), but can anyone w/ a lot of prod Solaris experience tell me if upgrading to Solaris 10 (to get at this feature or others) is really worth the effort?

          Is this mostly a developer tool, or is it useful to SAs, too?

          Are you seeing most 3d party software vendors supporting Solaris 10? Zones?

          • by bofkentucky (555107) <<bofkentucky> <at> <gmail.com>> on Thursday September 08, 2005 @02:21PM (#13511442) Homepage Journal
            On the telco side I'm seeing some of our apps being moved for solaris 2.6 only or solaris 8 only to 10, but its early and a lot of telco vendors branched out to SLES or RHAS since 8 was released. I'll be so glad to finally offline our last Solaris 2.6 boxes, they've served us well but they can be a bit of a pain to keep patched properly.
          • by assantisz (881107) on Thursday September 08, 2005 @03:28PM (#13512167)
            DTrace alone is a major reason why I am going to upgrade my production environment to Solaris 10 in the near future. DTrace takes most guessing work out of the trouble shooting process. All you need is to figure out what probes to use and with some programming and Kernel internals knowledge you can pinpoint your problem within moments.

            Features like the new SMF (aka launchd on Mac OS X) are a little turn-off IMHO, because it introduces XML and a full-blown database instance to something simple as the start-up process. I understand the advantages but it is going to be a new learning curve for seasoned Solaris admins.

            That said Solaris 10 is almost as important for Sun and will have big impact as Solaris 2.0 had when it replaced SunOS 4.x. Solaris 7 was also a very important milestone in Solaris's history.

          • by PsychoSid (683168) * on Thursday September 08, 2005 @03:34PM (#13512211)
            Whilst this is more of a development tool than an SA tool it can help SA's (I am a professional one with RHEL also).The IO profiling alone is now so easy to debug rather than go through veritas' vxtrace/vxstat for example

            The TCP/IP stack is nice, as is SMF.

            Although you can go to Sun's site to find out. I am no cheerleader for them.

      • Re:Wikipedia:DTrace (Score:4, Informative)

        by cant_get_a_good_nick (172131) on Thursday September 08, 2005 @10:54AM (#13509413)
        truss/strace is a syscall tracer. Anything in your app that makes a syscall gets it's arguments and return values logged. ltrace adds the ability to do the same with dynamic library calls.

        dtrace is much different, you have areas of your kernel that have probes, places that accumulate data. dtrace is a language where you can read these probe areas (including the syscall interface) and print them out to user level and figure out whats going on (wrong) in your kernel.

        For the people who say Sun isn't real about open source, they should realize this is a differentiating technology, years ahead of what anything in Linux/bsd or commercial linuxes have. If it's going into the BSD kernel, it's probably also BSD licensed, meaning all UNIXes can take this.
        • by cahiha (873942) on Thursday September 08, 2005 @11:37AM (#13509799)
          For the people who say Sun isn't real about open source, they should realize this is a differentiating technology,

          And that's why Sun and Solaris have been such smashing successes recently?

          Face it, most people would not know how to use DTrace if their life depended on it. That leaves the few who do. Many of those don't have a choice in platforms, so it's academic. And many of the performance problems gurus encounter and can fix are blatantly obvious anyway. And even if DTrace may be a little better, it's not like other operating systems don't have similar tools already. So, you are left with a tiny group of people who can possibly solve a few, rare obscure problems slightly faster with DTrace than with other tools, provided they spend time learning it. That's not much of a differentiator.

          In fact, the same is true for most of the stuff Sun and even Microsoft have been working on in order to "improve" their operating systems and justify new releases: they just don't matter.
          • by PsychoSid (683168) * on Thursday September 08, 2005 @03:41PM (#13512273)
            Trust me there are no tools like this on other *nix OSes out there.

            The company that I work for (huge/global etc). Whilst migrating some things to RHEL is leaving a lot of stuff on Solaris (currently 10000+ systems).

            Developers are attending special courses on Dtrace and they love it I think the benefits will be remarkable.

            If you see what this can do in a real-world scenario you will be suprised.

            • by cahiha (873942) on Friday September 09, 2005 @01:18AM (#13516238)
              Developers are attending special courses on Dtrace and they love it I think the benefits will be remarkable.

              And where are those benefits supposed to come from? Well-tuned applications already run close to what the hardware is capable of. Doing that isn't rocket science.

              Whilst migrating some things to RHEL is leaving a lot of stuff on Solaris (currently 10000+ systems).

              I pity you.
        • by renoX (11677) on Thursday September 08, 2005 @03:08PM (#13511993)
          Well, IMHO the probe that will be added in the kernel must be BSD licensed of course, and the rest will stay with the same license..
  • by Anonymous Coward on Thursday September 08, 2005 @10:33AM (#13509207)
    FreeBSD performance has generally been declining with each subsequent release in recent years. No one seems to be able to get to the bottom of the problem. It could be the effects of FreeBSD suffering from "creeping featuritis" combined with a bit of bloat.

    A tool like this could really aid in finding all the bottlenecks. Benchmarks have become an embarrassment for FreeBSD as of late, and it is really sad to see that FreeBSD has fallen so far behind. Hopefully this could start to turn things around.

  • by slave 6742 (703775) on Thursday September 08, 2005 @12:19PM (#13510163)
    I just have to post this due to amount of crap I get from the BSD fan club I associate with.

    start sarcasm

    But it is not BSD! It can't be better than anything BSD has created.

    We all know that Solaris is just a crappy system that has no use in the enterprise.

    end sarcasm

  • by dAzED1 (33635) <brianlamere AT yahoo DOT com> on Thursday September 08, 2005 @12:37PM (#13510321) Homepage Journal
    Linux can be build with "bsd-style process accounting" and as such, can this be made to work in Linux?
  • this is great (Score:2, Interesting)

    by mendicant_zero_x (911337) on Thursday September 08, 2005 @12:38PM (#13510327)
    It seems like everywhere I look I've heard comments about how great DTrace is, so to see it ported to FreeBSD really makes me happy. I do have a couple of questions about it though, simply going in line with the announcements over the last couple days.

    1) Considering the fact that we are currently going through the Beta's for FreeBSD 6, I am curious how, if at all, a fully implemented DTrace would help the devs with tracking down and solving the current beta problems. From my current understanding, it seems that it could be a great help with tracking down and solving the current show-stoppers. Can someone clarify this for me?

    2) I have also read an article somewhere where a DTrace dev showed how easy it was to track down a memory leak in a small program. With Gnome currently going on a memory reduction kick, would a fully featured DTrace be able to help with finding these memory problems? I realize that comparing Gnome with a small application is ridiculous so I can't expect it to magically find these problems in just a few minutes, but could it help? Also, if DTrace helped to find these problems on versions ported to FreeBSD, would they easily be ported back into the main linux-based version of Gnome?

    Any feedback would be appreciated because from what (admittedly little) I've read, it seems that DTrace could help on these fronts, but I'm really not 100% sure that it would.
  • by rubycodez (864176) on Thursday September 08, 2005 @12:50PM (#13510450)
    What with ZFS and Linux partitions being put off at least until 2006 it might be the *only* feature of Solaris 10 for now. Not to be confused with the "pains" that were added, like insipid way java management console plugins are added/admined, new hiding places for common admin/config files or how general installation is just a pain in the keister. Save yourself some trouble, GNU/Linux passed up Solaris about 2 years ago.
  • by dodell (83471) <dodell AT sitetronics DOT com> on Thursday September 08, 2005 @12:51PM (#13510459) Homepage
    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

    • by Anonymous Coward on Thursday September 08, 2005 @01:16PM (#13510681)
      Sounds great.

      By the way, you don't need to be root to run DTrace. The Solaris privelege model allows assignment of dtrace priveleges to users. So you can selectively allow users to trace their own processes are more.

      Are you planning to also support kernel level tracing? Dtrace is also really useful to Solaris kernel developers (my job) and allows tracing of kernel functions, system calls, etc.
    • From what I've heard, Sun is an entirely different sort of company, where the people like the Solaris Kernel Engineers are actually very in charge of direction taken. People that create a technology control that technology, it is as if the Market dweebs realize that they are the people that should be running the company, so they let the people in the know keep directional control. So yes, Sun is probably very happy with the FreeBSD port.
    • by Anonymous Coward on Thursday September 08, 2005 @02:43PM (#13511692)
      >When will this be in Linux? I don't know. I won't >be working on it. I challenge _you_ to do this :)

      Good challange! But isnt the big problem here the license issue? Someone can do something like dtrace but a port is hard...
      • by dodell (83471) <dodell AT sitetronics DOT com> on Thursday September 08, 2005 @03:21PM (#13512116) Homepage
        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.
        • by vga_init (589198) on Friday September 09, 2005 @01:12AM (#13516213) Journal
          I think that licensing is secondary.

          Certainly, licensing should be a primary issue. Before one does anything with a program, there needs to be an answer to the questions, "Who does it belong to? What am I allowed to do with it?" At the very least, those questions ought to be answered "Mine," and "Whatever I want." Ideally, it should be answered, "Ours, and we want." If it doesn't belong to you and you can't do certain things with it, you can only get by ignoring this for so long until it becomes a major issue.

          The GNU system exists because of free software; linux is what it is today because of free software. Licensing becomes an issue when the software doesn't belong to you and you don't have the freedom to do stuff with it.

          Your stance seems to contradict your "use what works best!" mentality. When there is a licensing issue, the water may be calm at the moment, but in the future some IP owner could potentially destroy your project or deny your use. Do you really want that to happen? You won't think it's so usable when your project is taken away from you (and this can happen in more ways than one).

          On a side note, I totally agree with you that FreeBSD is an easier target than linux. linux is more fragmented than FreeBSD (and don't get me wrong, this is a strength in many aspects, but it does make broad system changes more difficult).

          • by Anonymous Coward on Friday September 09, 2005 @01:29PM (#13520277)
            Certainly, licensing should be a primary issue.

            no no no... Licensing *is* secondary. Considering it primary is a sign of the dementia that is affecting the world today. A dementia that the GPL was created exactly to *fight*!

            Follow the spirit of GPL, not the license itself.
          • by dodell (83471) <dodell AT sitetronics DOT com> on Friday September 09, 2005 @06:52PM (#13523043) Homepage
            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.
            • by vga_init (589198) on Friday September 09, 2005 @09:07PM (#13523764) Journal
              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.

              Well, that's certainly everything I wanted to hear. I'm seeing your point a bit more clearly now, and while it's always debateable about how restrictive a license is or isn't as long as the licensing is such that you can legally use the software. It's a "right tool, right job" relationship.

          • by glitchvern (468940) on Saturday September 10, 2005 @08:44PM (#13528881) Homepage
            Certainly, licensing should be a primary issue.

            The ported parts are licensed under the cddl. I imagine some parts which reach deep into the kernel will require reimplementation as opposed to porting and it would make sense for those parts to be under a bsd license. The cddl is designated by the Free Software Foundation [fsf.org] as a Free Software GPL-incompatible license [fsf.org]. It is a derivative of the mozilla public license. Due to the requirements of the GPL it is easy to be GPL-incompatible. The LGPL is more sensible in this regard. Of course GPL-incompatibility is not a problem for a BSD licensed operating system. Being designated a Free Software license means it does protect the four freedoms [fsf.org] which all in the free software movement hold so dear. You can read the text of the CDDL here [opensolaris.org].
  • by kaffiene (38781) on Thursday September 08, 2005 @09:16PM (#13514792)
    ...for the slashbots to tell us why this is evil - everything Sun does is evil, after all.

Hacking's just another word for nothing left to kludge.

Working...