Slashdot Mirror


Solaris DTrace To Be Ported to FreeBSD

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

151 comments

  1. License? by rpbailey1642 · · Score: 3, Interesting

    The article doesn't say whether the program will be released under the BSD license (unlikely) or whether it will remain under the CDDL. The latter seems most likely.

    1. Re:License? by jonadab · · Score: 5, Insightful

      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.

      --
      Cut that out, or I will ship you to Norilsk in a box.
    2. Re:License? by Anonymous Coward · · Score: 0

      But most of DTrace is tightly integrated with the kernel. You can't do this thing without heavy kernel support.

      Obviously you can't just merge DTrace into FreeBSD and not have license issues. Likewise you probably couldn't just make it an optional part of the ports tree either, for technical reasons, due to its heavy kernel changes.

    3. Re:License? by m50d · · Score: 1

      Isn't FreeBSD committed to removing anything that isn't available under BSD license? That makes porting something non-BSD to it seem a step backwards.

      --
      I am trolling
    4. Re:License? by Z4rd0Z · · Score: 4, Insightful

      My guess is that any kernel changes will go into the FreeBSD base under the BSD license, and the DTrace tool itself will keep its current license and will be installed from the ports collection.

      Also, I don't think FreeBSD is committed to removing all non-BSD code.

      --
      You had me at "dicks fuck assholes".
    5. Re:License? by Anonymous Coward · · Score: 0

      Maybe you're thinking about OpenBSD. They're very gung-ho about removing non-BSD stuff. FreeBSD not so much. Can't attest to the others as I've not followed them closely.

    6. Re:License? by dodell · · Score: 4, Insightful

      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.

    7. Re:License? by NuShrike · · Score: 1

      You're thinking of OpenBSD, the great makers of pf, and OpenSSH.

      FreeBSD is mostly about making things work fast on x86.

  2. Good for Ruby! by fishdan · · Score: 5, Insightful
    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 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.

    --
    Nothing great was ever achieved without enthusiasm
    1. Re:Good for Ruby! by TheTomcat · · Score: 4, Informative

      There have been bindings for PHP for a few days, now.

      S

    2. Re:Good for Ruby! by jm91509 · · Score: 4, Insightful

      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.

    3. Re:Good for Ruby! by mccalli · · Score: 1
      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

    4. Re:Good for Ruby! by Anonymous Coward · · Score: 0
      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.

      That is not correct. The OS X kernel is a hybrid of Mach and FreeBSD. http://en.wikipedia.org/wiki/Xnu

    5. Re:Good for Ruby! by laffer1 · · Score: 2, Interesting

      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. :)

    6. Re:Good for Ruby! by evilviper · · Score: 2, Interesting
      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.
      --
      Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  3. When will it be available in Linux ? by UltimaGuy · · Score: 2, Interesting

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

    --
    "In questions of science the authority of a thousand is not worth the humble reasoning of a single individual."
    1. Re:When will it be available in Linux ? by brilinux · · Score: 5, Interesting

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

    2. Re:When will it be available in Linux ? by 10Ghz · · Score: 1

      Well, there WAS a smiley in the GP-post, in case you missed it...

      --
      Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
    3. Re:When will it be available in Linux ? by tsalaroth · · Score: 5, Insightful

      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.

    4. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 0

      There is no other tracing tool to compare with this.

      Yes, there is: SystemTap by Red Hat, IBM and Intel.

    5. Re:When will it be available in Linux ? by Zedrick · · Score: 3, Insightful

      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.

    6. Re:When will it be available in Linux ? by diegocgteleline.es · · Score: 3, Interesting

      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 of the linux symposium

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

      also there's a "linux trace toolkit". A post about LTT vs dtrace...whatever, too much flamewar for my taste.

    7. Re:When will it be available in Linux ? by diegocgteleline.es · · Score: 2, Informative
    8. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 0

      Never, Linux is dying :P

    9. Re:When will it be available in Linux ? by freshman_a · · Score: 3, Informative


      Yes, there is: SystemTap by Red Hat, IBM and Intel.

      Perhaps you should read

      http://groups.yahoo.com/group/solarisx86/message/2 7818

      and

      http://milek.blogspot.com/2005/08/linux-and-solari s.html

      Two discussions on some differences between SystemTap and Dtrace. (And yes, both links are in favor of Dtrace, and for good reason it appears.)

    10. Re:When will it be available in Linux ? by Short+Circuit · · Score: 3, Interesting

      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.

    11. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 5, Informative

      kprobes is not comparable to dtrace, to see a comparison between dtrace and kprobes check out
      dtrace vs. krpobes

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

    12. Re:When will it be available in Linux ? by TheRaven64 · · Score: 1

      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.

      --
      I am TheRaven on Soylent News
    13. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 0

      Solaris developer uses his blog to slag of competition -- news at 11.

    14. Re:When will it be available in Linux ? by Electrum · · Score: 1

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

    15. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 0

      Well, there WAS a smiley in the GP-post, in case you missed it...

      What makes you think he didn't notice, arsehole ;-)

    16. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 0

      Anytime you want to actually contribute and refute with examples or logic, feel free to pipe up.

      Thanks!

    17. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 1, Informative

      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.

    18. Re:When will it be available in Linux ? by JabrTheHut · · Score: 1

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

      --
      Work like no one is watching. Dance like you've never been hurt. Make love like you don't need the money.
    19. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 0

      I'm waiting for the OpenBSD folks to come out with "DTrace SSL."

    20. Re:When will it be available in Linux ? by speculatrix · · Score: 1
      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.

    21. Re:When will it be available in Linux ? by cbreaker · · Score: 0

      Um, actually, quite a few people (myself included) think you need to chill the hell out. He put a smiley, it sounded sarcastic, I took it as such - but you didn't because you're one of the BSDefenders.

      Don't be so defensive, it's just an OS!

      --
      - It's not the Macs I hate. It's Digg users. -
    22. Re:When will it be available in Linux ? by OrangeTide · · Score: 2, Informative

      Actually crux is closer to ports, and slackware + pkg-src is basically the same thing.

      --
      “Common sense is not so common.” — Voltaire
    23. Re:When will it be available in Linux ? by ahl_at_sun · · Score: 2, Informative

      That's not a Solaris developer (though I am) -- it's a customer who's been using DTrace for quite a while. He actually knows what he's talking about.

    24. Re:When will it be available in Linux ? by Some+Random+Username · · Score: 1

      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.

    25. Re:When will it be available in Linux ? by misleb · · Score: 1

      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

      --
      "THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
    26. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 0

      Lots of the time the GNU fans are complaining about options from XPG3 and XPG4 and other POSIX extended standards not being present, like the -f of ps.

    27. Re:When will it be available in Linux ? by halber_mensch · · Score: 5, Informative

      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

      --
      perl -e "eval pack(q{H*},join q{},qw{70 72696e74207061636b28717b482a7d2c717b343 637323635363534323533343430617d293b})"
    28. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 0
      kprobes is not comparable to dtrace, to see a comparison between dtrace and kprobes check out . . .


      This sentence make brain feel good.
    29. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 0

      You're such a rebel.

    30. Re:When will it be available in Linux ? by jonabbey · · Score: 1

      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.

    31. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 0

      What a load of crap. Systemtap is not being designed "without safety". The big difference is that dtrace uses only interpreted code, while systemtap uses interpreted code that is first converted to native code and then executed (giving systemtap SIGNIFICANT performance and functionality benefits over the camparatively poorly designed dtrace). If you or the poor engineers at Sun think dtrace is "safe" because it is interpreted then you are naive and have no experience with real world security issues. Yes, it might be in theory marginally more secure against dumb end users, but as everyone has discovered even the most "theoretically secure" designs can be compromised by a determined hacker. The security of dtrace is a red herring bantied about by Sun apologists.

    32. Re:When will it be available in Linux ? by tsalaroth · · Score: 1

      I never meant to imply that the ports system was perfect - in fact, I prefer Gentoo's portage over it, and am working on getting it installed on our OS X server.

      But yes, there's MUCH room for improvement in the "ports" system, but the concept is sound, and the idea of a system that builds the dependencies for you is great, IMHO.

      Anyways, back to the topic!

    33. Re:When will it be available in Linux ? by drsmithy · · Score: 3, Informative
      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.

      make package-recursive

    34. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 1, Informative

      well here is some more reading on the subject of how systemtap is flawed http://uadmin.blogspot.com/2005/08/systemtap-vs-dt race-debate-continues.html> systemtap debate

      RUNTIME issues:
      how do you sudgest you solve the halting problem?
      do you have a solution for errant pointers?
      and many more.

      compile time issues:

      You should read this latest tidbit from the systemtap mailing list, basicly it says that systemtap will not understand include files, so if you want to track data in a userland or kernel based struct. So you are then forced to use premade tapsets or expose your system to the unsafe mode. If and when userland probes are created there won't be anytap sets for your apps you created your self.

      from the systemtap mailing list

      > [...] Shouldn't systemtap be able to handle all of the standard
      > include files in /usr/include and the includes in a 2.6.x kernel so
      > users can monitor the system? [...]

      The debugging information associated with the kernel (and in the
      future, user-land applications) contains a form of that information.
      We already expose it to some extent, and will probably do so more as
      we gain experience. It is unlikely for systemtap to ever have to
      directly parse C files such as kernel headers.

      These are just a few of the issues, that systemtap faces. currently they are using work arounds that involve using "guru mode" for stuff that should of been dealt with from day one.

    35. Re:When will it be available in Linux ? by jonabbey · · Score: 1

      Thank you! I read the entire Porter's guide extensively and never came across that.

    36. Re:When will it be available in Linux ? by Some+Random+Username · · Score: 0, Flamebait

      GNUtards complaining about other systems not being posix compliant? That's pretty funny. The -f option to ps is an XSI extention, and doesn't need to exist since it gives you a subset of what other options give, and you can get precisely what you want/need with the -o option. Adding every random option under the sun, and creating bloated, broken utilities is not a good thing, although it does seem to be GNU policy. Then again, it takes some special people to make "man" exploitable.

      From all the posts on the lists I've seen, it would appear that most people coming from linux complain because they can't be bothered to read the man pages to see what the options they should be using are, and just complain that everything isn't the same as the last linux box they used. Hell, half the complaints are dumbasses who think that the BSDs have a broken rm because they do rm * and it doesn't ask them what files they want to delete.

    37. Re:When will it be available in Linux ? by Anonymous Coward · · Score: 0

      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.

      Actually no, the benchmarks say that Linux is faster than FreeBSD, and in some cases it is staggering. The last "benchmark" I saw where FreeBSD beat linux was a FreeBSD developer claiming that their stack could route 1Mpps, while Linux could "barely do 100Kpps". Unfortunately they were using different setups and to make things funnier, there were people doing over 1Mpps on Linux on a single CPU, and 2.1Mpps with 2 cpus.

    38. Re:When will it be available in Linux ? by drsmithy · · Score: 1
      Thank you! I read the entire Porter's guide extensively and never came across that.

      You might also want to try man ports then :).

  4. Tons of links in the article by ReformedExCon · · Score: 5, Interesting

    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?

    --
    Jesus saved me from my past. He can save you as well.
    1. Re:Tons of links in the article by Wesley+Felter · · Score: 1

      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.

    2. Re:Tons of links in the article by Anonymous Coward · · Score: 2, Informative

      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 do anything bad.

    3. Re:Tons of links in the article by ReformedExCon · · Score: 1

      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?

      --
      Jesus saved me from my past. He can save you as well.
    4. Re:Tons of links in the article by Anonymous Coward · · Score: 0

      Have you even heard of Google before? I assume since you have a GMail account you must be at least familiar with the search enging, give it a try sometime. Or is that too much to expect from a "criminal?"

    5. Re:Tons of links in the article by demi · · Score: 1

      Then how come it's news that ruby and php have been modified to be "dtrace" providers? This sounds more like an interface to tracing.

      --
      demi
  5. Linux had this for ages by Anonymous Coward · · Score: 2, Funny

    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)

    1. Re:Linux had this for ages by Hackeron · · Score: 5, Informative

      if you're referring to http://oprofile.sourceforge.net/news/, 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.

    2. Re:Linux had this for ages by Anonymous Coward · · Score: 0

      Did you read the parent post, or just the title?

    3. Re:Linux had this for ages by babyrat · · Score: 1

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

  6. Re:Insanely great by Elrac · · Score: 2, Funny

    I've seen it before, fairly often. Perhaps a bit of an exaggeration, but still - commonly used.

    Google shows 229,000 hits for "insanely great" (as a phrase).

    Welcome to, umm, Geek English!

    --
    When one person suffers from a delusion, it is called insanity. When many people suffer from a delusion it is called Rel
  7. Wikipedia:DTrace by Saiyine · · Score: 5, Informative


    For we that don't have a clue what DTrace is, here's what the 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 4800MB Storage, 120GB bandwidth, $7,95.
    Picaday! Soon to be open "Picture of the day web".

    --
    Hosting 20G hd, 1Tb bw! ssh $7.95
    1. Re:Wikipedia:DTrace by Willy+on+Wheels · · Score: 0

      The article is a stub at the moment. Lets put the slashdot effect into good use and expand it

      --
      Do you play with your Willy?
    2. Re:Wikipedia:DTrace by Tony+Hoyle · · Score: 1

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

    3. Re:Wikipedia:DTrace by davecb · · Score: 3, Informative
      It's way more fine-grained than truss or apptrace (which I helped build), and has overhead only when used.

      --dave

      --
      davecb@spamcop.net
    4. Re:Wikipedia:DTrace by cant_get_a_good_nick · · Score: 3, Informative

      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.

    5. Re:Wikipedia:DTrace by cahiha · · Score: 1

      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.

    6. Re:Wikipedia:DTrace by Anonymous Coward · · Score: 0

      The difference between Sun and Microsoft, though, is that I can go on the Sun website and download a copy of Solaris 10, and I could do this for Solaris years before it was open-source.

      How does that translate into profit for Sun? Shrug. If they really want to be successful they should lower the price of their hardware.

    7. Re:Wikipedia:DTrace by popechunk · · Score: 1
      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?

    8. Re:Wikipedia:DTrace by Anonymous Coward · · Score: 0

      this is where ready made dtrace scripts come into play.

      Brendan Gregg's Dtrace toolkit contains over 80 premade script that allows normal users to use dtrace to find stuff about there system that no other tool can. one small example

      connections snoop inbound TCP connections as they are established, displaying the server process that accepted the connection. Full example is here.

      # connections
          UID PID CMD TYPE PORT IP_SOURCE
              0 242 inetd tcp 79 192.168.1.1
              0 359 sshd tcp 22 192.168.1.1
          100 1532 Xorg tcp 6000 192.168.1.1

    9. Re:Wikipedia:DTrace by bofkentucky · · Score: 1

      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.

      --
      09f911029d74e35bd84156c5635688c0
    10. Re:Wikipedia:DTrace by renoX · · Score: 1

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

    11. Re:Wikipedia:DTrace by assantisz · · Score: 1
      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.

    12. Re:Wikipedia:DTrace by PsychoSid · · Score: 1
      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.

    13. Re:Wikipedia:DTrace by PsychoSid · · Score: 1
      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.

    14. Re:Wikipedia:DTrace by Anonymous Coward · · Score: 0

      I had a problem with a database that stores each
      table is a seperate file. Every few hours a
      database session returned an invalid file descriptor error.

      This was under AIX 4.2.1 so no truss like abilities unless you bought the performance toolbox. Try asking a small customer for a few
      thousand pounds addon when the database is crashing!

      Truss would be too slow anyway. You need to only
      amend the code path that is executed for open/close/read/write functions.

      Never did track down the problem but the drive
      failed a few days later and there were no more
      errors for at least 6 months with the same code
      once a new drive was installed.

      I suspect a i/o error caused the database server to close the file and then get an invalid file descriptor error somewhere else in the code
      before it return an error code to the application
      hence the application gets an invalid file
      descriptor error.

      How would you trace that on a production system
      with lots of users..truss every session to the
      database? We turned on a database debug option
      that a) caused queries to take 10 minutes+
      b) filled the available disk space in a few hours with logging info.

      Bet I could write a dtrace script to track
      file open's/close/reads/writes and and log
      which file descriptor corresponds to which open
      file and what function returns an invalid file
      descriptor error.

      an invalid file descriptor error and which file

    15. Re:Wikipedia:DTrace by cahiha · · Score: 1

      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.

  8. Re:Insanely great by dylan_- · · Score: 5, Informative


    "insanely great" is well known. In fact, it's in the Jargon File

    --
    Igor Presnyakov stole my hat
  9. Re:DTrace kicks ass by Anonymous Coward · · Score: 0

    Wow. I didn't think anyone would even put that much effort into a troll. I mean it shows quite a lot of ignorance and stupidity to be sure, but under the guise of being almost intelligent.

    Must be sad, living your life. Be content in knowing you'll be dead someday.

  10. FreeBSD really needs this by Anonymous Coward · · Score: 5, Interesting
    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.

    1. Re:FreeBSD really needs this by dodell · · Score: 4, Interesting

      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.

    2. Re:FreeBSD really needs this by Billly+Gates · · Score: 3, Insightful

      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.

    3. Re:FreeBSD really needs this by doodlelogic · · Score: 1

      If the post was moderated as troll because it was offtopic, then it was moderated wrongly. For guidance, this post should be moderated -1, Offtopic.

  11. Re:MOD PARENT UP! by Alranor · · Score: 1

    the best damn piece on slashdot and some moron marked it flamebait. I've modded it up as much as I can (a big +1 whoo!)

    And then proceeded to cancel that moderation by posting in the story.

    Let me guess, you must be new here?

  12. Re:MOD PARENT UP! by RouterSlayer · · Score: 1

    my +1 was already cancelled by someone else modding it as flamebait, so it didn't matter.

    which is why I posted...

    sigh...

    weird tho, the score is the same as before I posted.
    so someone else modded it up +1 to cancel the cancel on my +1 ? erg, you're making my brain hurt!
    bad slashdot user, bad! ;)

  13. Re:DTrace kicks ass by Anonymous Coward · · Score: 0

    Gah.... I've just found you can also read this tripe on several other sites. I had to look, I was curious........

  14. Re:Insanely great by moonbender · · Score: 0

    Maybe he thought it was a typo for "insanely grate".

    --
    Switch back to Slashdot's D1 system.
  15. Re:Insanely great by Anonymous Coward · · Score: 0

    You know, I've read a lot of software reviews, but I don't think I've ever seen the "insanely" used as an adverb before...

    They're called context clues smart guy. I learned about them in like second grade. Although IANAGE (I Am Not A Grammar Expert) I could have figured out what "insanely great" means in the second grade.

  16. Re:Insanely great by Anonymous Coward · · Score: 0

    Mac community, from Steve Jobs; also BSD Unix people via Bill Joy. Something so incredibly elegant that it is imaginable only to someone possessing the most puissant of hacker-natures.

    So, it's a derogatory term?

    Seriously, neither Bill Joy, and least of all Steve Jobs, strike me as being able to have an informed opinion on elegant software implementations. Jobs has good design taste, but that's different.

  17. Re:Insanely great by Anonymous Coward · · Score: 0

    I don't care what ESR or his Aunt Tillie think.

    That said, I have no objection to the word "insanely".

  18. But!!! by slave+6742 · · Score: 1
    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

    --
    HGTTG: "I knew that there was something fundementally wrong with the Universe."
  19. FreeBSD? what's that? you're breathing? by Anonymous Coward · · Score: 0

    OMFG!!! IT'S ALIVE !!!!!!

  20. bsd-style proc accounting? by dAzED1 · · Score: 1

    Linux can be build with "bsd-style process accounting" and as such, can this be made to work in Linux?

  21. this is great by mendicant_zero_x · · Score: 2, Interesting

    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.

    --
    "You look so different now, but looks can be deceiving." -- Snuff
    1. Re:this is great by dodell · · Score: 4, Informative

      On 1):

      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.

      Hope this is useful information.

      --Devon

    2. Re:this is great by mendicant_zero_x · · Score: 1

      Very helpful.

      Thanks for the link.

      --
      "You look so different now, but looks can be deceiving." -- Snuff
  22. "best" feature of Solaris 10 by rubycodez · · Score: 0, Flamebait

    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.

    1. Re:"best" feature of Solaris 10 by turgid · · Score: 1, Flamebait
      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...

    2. Re:"best" feature of Solaris 10 by Anonymous Coward · · Score: 0

      turgid was laid off from Sun, so keep that in mind when you read his screeds against various Solaris technologies...

    3. Re:"best" feature of Solaris 10 by turgid · · Score: 1
      Yes, keep that in mind. I'm a bitter and twisted old man.

      I seem to remember being quite supportive of Solaris around here, and the Sun engineers.

      Now, the PHBs. That's a different story.

      Just for the record: Solaris : good, Java : good, RedHat : bad.

      Opteron : good. UltraSPARC : mediocre and falling behind.

      Pentium : bad.

      Linux : OK. Solaris : better.

      Windows : Bad.

      Unrestrained capitalism : bad.

      I hope that clears a few things up. If you want to know my shoe size and inside leg measurement, just ask.

    4. Re:"best" feature of Solaris 10 by rubycodez · · Score: 1

      but I've only been a Sun customer most of my life; please explain my bitterness and angst.

    5. Re:"best" feature of Solaris 10 by assantisz · · Score: 1

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

    6. Re:"best" feature of Solaris 10 by Anonymous Coward · · Score: 0

      Don't let the facts stand in the way of a good Linux inspired Solaris bashing.

    7. Re:"best" feature of Solaris 10 by PsychoSid · · Score: 1
      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.

    8. Re:"best" feature of Solaris 10 by rubycodez · · Score: 1

      WAN boot, SCF, NFSv4, & IPQoS existed in Solaris 9. SMF and new TCP/IP stack and "Least Privileges" are interesting. Overall, the grade is still "thumbs down"

  23. Clear up a few things by dodell · · Score: 5, Informative

    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

    1. Re:Clear up a few things by Anonymous Coward · · Score: 1, Informative

      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.

    2. Re:Clear up a few things by dodell · · Score: 2, Informative

      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.

    3. Re:Clear up a few things by ak3ldama · · Score: 1

      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.

      --
      "but money is the God of Algiers & Mahomet their prophet." - Rich. O'Bryen June 8th 1786
    4. Re:Clear up a few things by Anonymous Coward · · Score: 1, Interesting

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

    5. Re:Clear up a few things by Anonymous Coward · · Score: 0

      Fact: FreeBSD is dying

    6. Re:Clear up a few things by dodell · · Score: 4, Informative

      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.

    7. Re:Clear up a few things by vga_init · · Score: 2, Insightful
      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).

    8. Re:Clear up a few things by Anonymous Coward · · Score: 1, Insightful

      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.

    9. Re:Clear up a few things by dodell · · Score: 1

      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.

    10. Re:Clear up a few things by vga_init · · Score: 1
      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.

    11. Re:Clear up a few things by glitchvern · · Score: 1
      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 as a Free Software GPL-incompatible license. 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 which all in the free software movement hold so dear. You can read the text of the CDDL here.
  24. Re:MOD PARENT UP! by Anonymous Coward · · Score: 0


    the best damn piece on slashdot

    yeah, an anti-freebsd rant posted to an article about freebsd, how fucking original. let me guess, netcraft confirms BSD is dying, right?

    some moron marked it flamebait.

    the only moron i see here is you. you bitch about about flamebait being modded as such. no one cares how you used your mod points. get a fucking life.

  25. Re:MOD PARENT UP! by Anonymous Coward · · Score: 1, Interesting

    Brilliant? This guy has been posting the same damn thing lifted from a FreeBSD mailing list in every FreeBSD-related article for months.

    And what does it mean that a former FreeBSD core member admits that FreeBSD is dying? Well, in my opinion FreeBSD's leadership has been a little out of touch lately. That doesn't mean that OpenBSD, NetBSD, and now DragonFly (for the disaffected FreeBSD people) can't continue kicking ass.

  26. Looking for a DragonFlyBSD Port by Anonymous Coward · · Score: 0

    I'm looking for someone clueful to port DTrace to DragonFlyBSD instead. FreeBSD has too many projects where they announce they're going to do something and then never finish. Just look at any of their past status reports. They read like tombstones for unfinished projects. Or consider FreeBSD 5-SMP --- another unfinished project they're sweeping under the rug. At least in DragonFlyBSD, they do what they say they're going to do. More in fact. They do it first then say they've done it.

    1. Re:Looking for a DragonFlyBSD Port by Anonymous Coward · · Score: 0
      FreeBSD has become the Queen of the Vapors. They never announce real accomplishments anymore. If there is an announcement from FreeBSD you can be sure that it is something that doesn't exist yet, and in all likelihood may never exist.

      It is should be mentioned that FreeBSD is the only project outside of Microsoft which habitually promotes vaporware. Neither OpenBSD, NetBSD, Linux, Dragonfly, or any other project suffers from this pathetic practice.

    2. Re:Looking for a DragonFlyBSD Port by chrysalis · · Score: 1

      Why has parent been mod'ed down?

      Check facts, this is true.

      --
      {{.sig}}
  27. Waiting... by kaffiene · · Score: 1

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

  28. your .sig by T.Hobbes · · Score: 1

    How does it work? That's some seriously obfuscated code!

    1. Re:your .sig by halber_mensch · · Score: 1
      :) 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/;
      --
      perl -e "eval pack(q{H*},join q{},qw{70 72696e74207061636b28717b482a7d2c717b343 637323635363534323533343430617d293b})"
  29. Zonk.. front page worthy? by netmask · · Score: 0, Offtopic

    Zonk,

    Why do you think all of your worthless posts are worth of the front page?

    Why don't you start posting every new release on Freshmeat to the front page as a full article?

    Also, you don't ever check your E-Mail do you. Probably at quota with flames.

  30. Requiem for the FUD by Anonymous Coward · · Score: 0
    // Please *don't* mod this up. It has already been done! Thx

    ... facts are facts. ;)

    FreeBSD:
    FreeBSD, Stealth-Growth Open Source Project (Jun 2004)
    "FreeBSD has dramatically increased its market penetration over the last year."
    Nearly 2.5 Million Active Sites running FreeBSD (Jun 2004)
    "[FreeBSD] has secured a strong foothold with the hosting community and continues to grow, gaining over a million hostnames and half a million active sites since July 2003."
    What's New in the FreeBSD Network Stack (Sep 2004)
    "FreeBSD can now route 1Mpps on a 2.8GHz Xeon whilst Linux can't do much more than 100kpps."

    NetBSD:
    NetBSD, for When Portability and Stability Matter (Oct 2004)
    NetBSD sets Internet2 Land Speed World Record (May 2004)
    NetBSD again sets Internet2 Land Speed World Record (Sep 2004)

    OpenBSD:
    OpenBSD Widens Its Scope (Nov 2004)
    Review: OpenBSD 3.6 shows steady improvement (Nov 2004)
    OpenSSH (OpenBSD subproject) has become a de facto Internet standard.

    *BSD in general:
    Deep study: The world's safest computing environment (Nov 2004)
    "The world's safest and most secure 24/7 online computing environment - operating system plus applications - is proving to be the Open Source platform of BSD (Berkeley Software Distribution) and the Mac OS X based on Darwin."
    BSD Success Stories (O'Reilly, 2004) (pdf) ~ from Onlamp BSD DevCenter
    "The BSDs - FreeBSD, OpenBSD, NetBSD, Darwin, and others - have earned a reputation for stability, security, performance, and ease of administration."
    ..and last but not least, we have the cutest mascot as well - undisputedly. ;)

    --
    Being able to read *other people's* source code is a nice thing, not a 'fundamental freedom'.

  31. Same old Linux FUD... by Anonymous Coward · · Score: 0

    Same old GNU/Linux FUD, that has been disproved countless times..
    In short: the MIT research is *11 years old*, and that Rice study on the TCP/IP stack uses FreeBSD *2.2.6*.

    (And btw, Eric Raymond advocates BSD license over GPL.) :)