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

Comments

License?

[rpbailey1642]

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.

Re:License?

[jonadab]

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.

Re:License?

[m50d]

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.

Re:License?

[Z4rd0Z]

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.

Re:License?

[dodell]

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.

Re:License?

[NuShrike]

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

FreeBSD is mostly about making things work fast on x86.

Good for Ruby!

[fishdan]

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.

Re:Good for Ruby!

[TheTomcat]

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

S

Re:Good for Ruby!

[jm91509]

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!

[mccalli]

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!

[laffer1]

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

Re:Good for Ruby!

[evilviper]

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.

When will it be available in Linux ?

[UltimaGuy]

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 ?

[brilinux]

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

Re:When will it be available in Linux ?

[10Ghz]

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

Re:When will it be available in Linux ?

[tsalaroth]

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.

Re:When will it be available in Linux ?

[Zedrick]

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.

Re:When will it be available in Linux ?

[diegocgteleline.es]

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.

Re:When will it be available in Linux ?

[diegocgteleline.es]

(soon to be merged in mainline)

Oh well, it's already there and it seems to have been there for ages: http://kernel.org/git/?p=linux/kernel/git/torvalds /linux-2.6.git;a=blob;h=f3ea492ab44dfcfc05e2fad402 7e303f9b69d9dd;hb=caf39e87cc1182f7dae84eefc43ca14d 54c78ef9;f=kernel/kprobes.c

Re:When will it be available in Linux ?

[freshman_a]

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

Re:When will it be available in Linux ?

[Short Circuit]

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.

Re:When will it be available in Linux ?

[Anonymous Coward]

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.

Re:When will it be available in Linux ?

[TheRaven64]

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.

Re:When will it be available in Linux ?

[Electrum]

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.

Re:When will it be available in Linux ?

[Anonymous Coward]

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.

Re:When will it be available in Linux ?

[JabrTheHut]

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

Re:When will it be available in Linux ?

[speculatrix]

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.

Re:When will it be available in Linux ?

[OrangeTide]

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

Re:When will it be available in Linux ?

[ahl_at_sun]

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.

Re:When will it be available in Linux ?

[Some Random Username]

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 ?

[misleb]

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

Re:When will it be available in Linux ?

[halber_mensch]

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

Re:When will it be available in Linux ?

[jonabbey]

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.

Re:When will it be available in Linux ?

[tsalaroth]

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!

Re:When will it be available in Linux ?

[drsmithy]

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

Re:When will it be available in Linux ?

[Anonymous Coward]

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.

Re:When will it be available in Linux ?

[jonabbey]

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

Re:When will it be available in Linux ?

[drsmithy]

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

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

Tons of links in the article

[ReformedExCon]

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?

Re:Tons of links in the article

[Wesley Felter]

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.

Re:Tons of links in the article

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

Re:Tons of links in the article

[ReformedExCon]

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

[demi]

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.

Linux had this for ages

[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

[Hackeron]

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.

Re:Linux had this for ages

[babyrat]

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

Re:Insanely great

[Elrac]

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!

Wikipedia:DTrace

[Saiyine]

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

Re:Wikipedia:DTrace

[Tony Hoyle]

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

[davecb]

It's way more fine-grained than truss or apptrace (which I helped build), and has overhead only when used.

--dave

Re:Wikipedia:DTrace

[cant_get_a_good_nick]

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.

Re:Wikipedia:DTrace

[cahiha]

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.

Re:Wikipedia:DTrace

[popechunk]

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?

Re:Wikipedia:DTrace

[bofkentucky]

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.

Re:Wikipedia:DTrace

[renoX]

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

Re:Wikipedia:DTrace

[assantisz]

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.

Re:Wikipedia:DTrace

[PsychoSid]

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

[PsychoSid]

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.

Re:Wikipedia:DTrace

[cahiha]

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.

Re:Insanely great

[dylan_-]

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

FreeBSD really needs this

[Anonymous Coward]

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

[dodell]

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

[Billly Gates]

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.

Re:FreeBSD really needs this

[doodlelogic]

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.

Re:MOD PARENT UP!

[Alranor]

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?

Re:MOD PARENT UP!

[RouterSlayer]

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

But!!!

[slave 6742]

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

bsd-style proc accounting?

[dAzED1]

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

this is great

[mendicant_zero_x]

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.

Re:this is great

[dodell]

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

Re:this is great

[mendicant_zero_x]

Very helpful.

Thanks for the link.

Clear up a few things

[dodell]

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

[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

[dodell]

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.

Re:Clear up a few things

[ak3ldama]

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

[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

[dodell]

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.

Re:Clear up a few things

[vga_init]

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

Re:Clear up a few things

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

Re:Clear up a few things

[dodell]

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.

Re:Clear up a few things

[vga_init]

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.

Re:Clear up a few things

[glitchvern]

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.

Re:"best" feature of Solaris 10

[turgid]

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

Re:"best" feature of Solaris 10

[turgid]

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.

Re:"best" feature of Solaris 10

[rubycodez]

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

Re:MOD PARENT UP!

[Anonymous Coward]

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.

Re:"best" feature of Solaris 10

[assantisz]

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

Re:"best" feature of Solaris 10

[PsychoSid]

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.

Re:"best" feature of Solaris 10

[rubycodez]

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"

Waiting...

[kaffiene]

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

your .sig

[T.Hobbes]

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

Re:your .sig

[halber_mensch]

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

Re:Looking for a DragonFlyBSD Port

[chrysalis]

Why has parent been mod'ed down?

Check facts, this is true.