Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
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 More

Solaris DTrace To Be Ported to FreeBSD

Comments Filter:

  • License? (Score:3, Interesting)

    by rpbailey1642 ( 766298 ) <robert.b.prattNO@SPAMgmail.com> on Thursday September 08, 2005 @08: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.

    • Re:License? (Score:5, Insightful)

      by jonadab ( 583620 ) on Thursday September 08, 2005 @08:52AM (#13508878) Homepage Journal
      Why would this occasion a license change? It's a *port*, as in, the code will now run on more systems than it used to. Licensing doesn't have anything to do with that; it's still fundamentally the same codebase, so I'm sure the code will still be covered by the same licensing terms it already was released under.

      To create a BSD-licensed version, someone would have to *clone* it, which is different from porting.

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

    by fishdan ( 569872 ) * on Thursday September 08, 2005 @08: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 @09: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 @10: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 )

        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

    • 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 )
      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 y
  • 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 ;-)

    • Re:When will it be available in Linux ? (Score:5, Interesting)

      by brilinux ( 255400 ) on Thursday September 08, 2005 @08:50AM (#13508853) 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...
      • Well, there WAS a smiley in the GP-post, in case you missed it...
      • 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 f

        • Re:When will it be available in Linux ? (Score:5, Informative)

          by halber_mensch ( 851834 ) on Thursday September 08, 2005 @01: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

          • How does it work? That's some seriously obfuscated code!
            • :) 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' th

    • Re:When will it be available in Linux ? (Score:5, Insightful)

      by tsalaroth ( 798327 ) <tsal@arikel.net> on Thursday September 08, 2005 @09: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.
    • 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.
      • 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.
        • 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.
        • 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.

    • Re:When will it be available in Linux ? (Score:4, Interesting)

      by diegocgteleline.es ( 653730 ) on Thursday September 08, 2005 @09: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.
    • 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...

  • Tons of links in the article (Score:5, Interesting)

    by ReformedExCon ( 897248 ) <reformed.excon@gmail.com> on Thursday September 08, 2005 @08: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?
    • I wonder what the performance penalty is when the tool is turned off.

      None. DTrace patches code when you use it, and then un-patches itself when you're done.
      • I'm curious. Does it seek out function signatures (i.e. push params onto the stack and branch) and insert itself automatically?

        Does it swap out normal binaries for instrumented binaries on the fly?

        How is it able to manage a zero penalty hit?

    • Re:Tons of links in the article (Score:2, Informative)

      by Anonymous Coward
      There is no overhead when off or need to pre-instrument points to be traced. Dtrace dynamically inserts a probe point into the code path wherever you want it, typically at a function entry/exit point.
      The overhead when in use is low enough that you can turn on a blanket Dtrace of all functions in the kernel without killing the OS. If you target your trace points sensibly the overhead is low enough that its not an issue. Its designed to be safe to use, so the Dtrace scripts that do in-kernel filtering can't d

  • Linux had this for ages (Score:2, Funny)

    by Anonymous Coward
    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)

    • Re:Linux had this for ages (Score:5, Informative)

      by Hackeron ( 704093 ) on Thursday September 08, 2005 @09: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.
      • No, i'm pretty sure he was being sarcastic...I'm sure the dept of homeland security is not really afraid of FreeBSD finding their last bug.

        Although perhaps the voices were right...who's to say...

  • Wikipedia:DTrace (Score:5, Informative)

    by Saiyine ( 689367 ) on Thursday September 08, 2005 @08: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".
    • 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 ) * <davecb@spamcop.net> on Thursday September 08, 2005 @09: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

        • 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?

          • 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.
          • 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-

          • 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 @09: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.
        • 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
          • 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.

            • 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.
        • 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..

  • FreeBSD really needs this (Score:5, Interesting)

    by Anonymous Coward on Thursday September 08, 2005 @09: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.

    • Re:FreeBSD really needs this (Score:5, Interesting)

      by dodell ( 83471 ) <dodell@sTEAitetronics.com minus caffeine> on Thursday September 08, 2005 @11:58AM (#13510528) Homepage
      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.

      • Re:FreeBSD really needs this (Score:4, Insightful)

        by Billly Gates ( 198444 ) on Thursday September 08, 2005 @12:16PM (#13510684) Journal
        I think the point of the moderation of the parent had to due with being offtopic with Drace in order to trash FBSD and cause a flamewar.

        I do agree with the parent poster as well since the threading and the code quality has made many old FBSD timers leave and work on Dragonfly. I no longer run FBSD as a result.

        But I wold mod the parent down for the that reason. However I would mod him up if it was a general FBSD post about i/o or BSD vs Linux story.

  • 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

  • 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 )
    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 seem
  • 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.
    • Yes, Sun did a remarkable job of shooting itself in the foot with its schedule and feature set for Solaris 10. Project "Flatline" (aka Greenline - the windows-style registry) went in at the expense of ZFS and Linux emulation.

      Then there was a slight HR issue with many of the engineers...

      • ZFS isn't too bad for those who have tested it.

        SMF, new IP stack, zones (whilst not true virtualisation is a good start) blah blah blah

        Whilst I am no cheerleader for Sun. I think some hardware lines are poor - I do SA callout work on Solaris/Linux and it has kept me up a few times. Solaris is a quality rock-solid OS.

    • Don't forget SMF, Zones, the new TCP/IP stack ("FireEngine"), NFS v4, SCF, Least Privileges, WAN Boot, and IPQos.

  • Clear up a few things (Score:5, Informative)

    by dodell ( 83471 ) <dodell@sTEAitetronics.com minus caffeine> on Thursday September 08, 2005 @11:51AM (#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

    • Re:Clear up a few things (Score:1, Informative)

      by Anonymous Coward
      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.

      • Re:Clear up a few things (Score:3, Informative)

        by dodell ( 83471 )
        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.
    • 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.

    • Re:Clear up a few things (Score:1, Interesting)

      by Anonymous Coward
      >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...

      • Re:Clear up a few things (Score:5, Informative)

        by dodell ( 83471 ) <dodell@sTEAitetronics.com minus caffeine> on Thursday September 08, 2005 @02: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.
        • 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 maj

          • Re:Clear up a few things (Score:1, Insightful)

            by Anonymous Coward
            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.
          • 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 tar
            • 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.

          • 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 sens

  • ...for the slashbots to tell us why this is evil - everything Sun does is evil, after all.

Slashdot Top Deals

To be awake is to be alive. -- Henry David Thoreau, in "Walden"

Close