Sun Microsystems told NewsForge/ITMJ Thursday that it intends to open source a small but important new feature in Solaris 10 — Dynamic Tracing (DTrace), a new framework for troubleshooting the network and tuning system performance in real time.
Sun to announce open source DTrace on Tuesday
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I thought they were going to wait til the 31st.
Oh well can’t complain….
I wonder if we will see a repeat of the Solaris 10 vs. Linux (as in Redhat in Sun’s eyes) with DTrace. As most of you know the Linux Trace Kit / relayfs does a similar job as DTrace.
Stop to compare DTRACE with your LTK, relayfs or any ktrace on linux.
There are not the same, you need to learn about DTRACE instead of launching FUD like yours.
FUD – I think perhaps this is going to be the most over-used term in 2005…he/she is correct in saying that that LTT and other tools for GNU/Linux do a similar job to DTrace, you are right in saying that they are not the same. Not that any such thing was implied.
Stop to compare DTRACE with your LTK, relayfs or any ktrace on linux.
There are not the same, you need to learn about DTRACE instead of launching FUD
—-
they aer very very similar. add kprobes to the list too. stop calling everything FUD
http://www.ppcnux.com/modules.php?name=News&file=article&sid=4681
FUD – Fear, Uncertainty, Doubt.
Now if we could just get people to use it where appropriate instead of juest whenever they disagree.
let’s just see if we can get through the rest of the posts here without using it again (References to Elmer Fud are exempt)
they aer very very similar. add kprobes to the list too.
Except they’re not. That little D on the front, for “dynamic”, is what makes the difference. DTrace is a dynamic facility and has no impact on performance when not in use, whereas kprobes require static entry points which slow kernel operation while not in use.
when not in use, whereas kprobes require static entry points which slow kernel operation while not in use.
—
not true anymore. read the kprobe list for more details
http://www-124.ibm.com/linux/projects/kprobes/
—-
you will see something called *d*probes. guess what d stands for?
> you will see something called *d*probes. guess what d stands for?
Dtrace is the fundamentally different from any attempt of implementing similar functionality in Linux realm. Read Dtrace documentation.
i suppose that CDDL is not compatible to GPL, so we would have no chance to see it ported to linux kernel? pity then…
Where is the rest of Solaris 10 ? I thought that was supposed to be released Sometime now.
Pretty neat stuff being able to trace the calls and function of processes.
Its a good tool to figure out what to fix on a box.
Their new method of starting services is neat and all xml based but they keep the legacy init system around. Its kind of an odd next step in my opinion the way they pull it off.
There are a lot of neat things about Solaris 10 and some nice kernel and fs level speed improvements but the container idea is interesting but not that appealing to me right off the bat.
The new init system is xml based but there are no files anywhere? So its on its own special filesystem or something. Very odd.
It seems almost like they tried too hard to innovate.
All I wanted out of Solaris is better performance, gnu level of options in basic commands shipped, elimination of all the odd legacy paths on the filesystem and speaking of which a lightning fast filesystem.
They are trying imo a little too hard to re-invent that damn nasty wheel.
> The new init system is xml based but there are no files anywhere? So its on its own special filesystem or something. Very odd.
Check the /var/svc directory for the profiles and manifest directories that contain the xml files describing the services controled by SMF, it is very simple really.
Thanks man. I was told they were no corresponding files for the xml service profile.
Thank you. I should no better to trust a training rep.
Dtrace is the fundamentally different from any attempt of implementing similar functionality in Linux realm. Read Dtrace documentation.
—-
keep telling this. you read this
http://www-124.ibm.com/developerworks/oss/linux/projects/dprobes/
and the relevant papers
and you get this:
http://berrange.com/bitsbobs/mlp/2004/07/dtrace
fair comparison, and pretty much says it all, methinks. and that’s a *redhat* employee…
So what I understand is that Linux has DTrace alike tools. You have the Ferrary (DTrace) on Solaris 10 and probably 10 VWs (DProbe, KProbe, OProfile, … etc) on Linux. If they both get you from point A to point B and that’s what you want then you can say they are alike.
FUD is a distant third or fourth.
So, if there’s an announcement that Sun will announce it on Tuesday, doesn’t this pre-announcement count as the actual announcement, cuz now they’re not announcing anything new Tuesday as we already know what they’re going to announce.
lol?!?!?!?!?!?
While it is entertaining to see everyone argue over how great or not DTrace is for Sun/Solaris and if it has a decent competitor in the Linux/GNU community – how many of you are actually going to use this feature regularly?
I doubt any of us here will activate it more than a few times just for the novelty-factor.
What i miss most on linux when developing is Compuwares’ DriverStudio which contains Softice, GDB, DDD just dont cut it. They can be used but its not as fast as those tools. http://pice.sourceforge.net/ might be there someday, havent tried it though.
> What i miss most on linux when developing is Compuwares’ DriverStudio which contains Softice, GDB, DDD just dont cut it. They can be used but its not as fast as those tools. http://pice.sourceforge.net/ might be there someday, havent tried it though.
Why don’t GDB/DDD cut it? Specific features?
Yes, they’re not kernel mode debuggers (other debuggers which are exist on linux), and yes ptrace sucks; but aside from that, what do you think the major shortcomings are?
“Why don’t GDB/DDD cut it?”
It’s been a while since I tried GDB, but when I used Sun’s dbx debugger, it was a “one stop shop” for not only basic tracing and data examination but also memory leak detection and bounds checking. It really made tracking down obscure bugs in C programs easier. I also had good luck with Sun’s lint tool tracking down ommissions from header files and finding unused code.
IMO, the GNU tools really are lacking in the software development department, and I think people use them for lack of a better free alternative. Look inside configure scripts, for example (yecch). Tools are just one of those things that people will make just barely tolerable to be able to do other work, which is the state of the free tools, right now.
“how many of you are actually going to use this feature regularly?”
From what people are saying about Dtrace, it seems programmers might want to keep Solaris 10 around if only for profiling and other analysis. Even if the deployment platform is not Solaris 10, the potential optimizations would carry over to other platforms.
Silly, A utility is not found in the kernel, its installed on the OS. Like all the gnu tools can also run on BSD and the bsd tools can run on linux
DTrace in not only for developers. It’s a perfect tool for system admins in their day-to-day work. Want to know which application is making that much IOs? Want to profile your network traffic by application? Which proccess is cousing page faults? What application and why is eating your CPU? And so on… after some time you end-up with your own D scripts for certain sys admin tasks. This is one of most common misunderstanding about DTrace – that it is tool only for developers. Well, while it’s great tool for developers it’s a must tool for sys admins too. And it’s production ready – I mean it’s safe to use, you can’t crash system or application due to mistake in your D scripy, which is not the case in DProbes, etc. And DTrace is much more simpler to use then Linux DProbes/KProbes.
You can find some examples here http://users.tpg.com.au/adsln4yb/dtrace.html
Hawkins, you silly too. DTrace must have support from kernel!! Think twice before bullshiting man.
keep telling this. you read this
http://www-124.ibm.com/developerworks/oss/linux/projects/dprobes/
and the relevant papers
Thanks for the pointer. This section particularly is very interesting. Dtrace particularly gaurds against this and is safe for use all the time, no insruction boundry restrictions or anything.
4. Security Considerations
————————–
Since this is a very low-level facility that operates in kernel mode and
provides almost unrestricted access to hardware registers and memory, it
needs to be used with caution. Only the root user has the authority to use
this facility.
Special care should be taken to make sure that the probe location specified
lies on an instruction boundary. If a probe is placed in the middle of an
instruction then the behaviour of the system may be unpredictable – it could
lead to data corruption or a system crash.
Dynamic Probes facility should be used only through the dprobes utility
provided. The dprobes system call should not be called directly by other
applications as the utility provided some extra safety checks that are
not done in the kernel. So, calling the dprobes syscall directly with
incorrect parameters could easily crash the system.
> It’s been a while since I tried GDB, but when I used Sun’s dbx debugger, it was a “one stop shop” for not only basic tracing and data examination but also memory leak detection and bounds checking. It really made tracking down obscure bugs in C programs easier. I also had good luck with Sun’s lint tool tracking down ommissions from header files and finding unused code.
Gcc has a lot of options, like -Wall and -pedantic; -Wall doesn’t actually turn on anything near all of the warnings you can convince gcc to give you. valgrind provides memory leak detection. The tools are there; I’m not sure how well various front-ends like kdevelop integrate them, but in terms of memory leaks/etc, there are good free tools. Gdb doesn’t serve the same function as them; it’s ok (not great, admittedly – libbfd, ptrace, yuck), but just because it doesn’t have a feature doesn’t mean you can’t find it anywhere in the free software world.
> IMO, the GNU tools really are lacking in the software development department, and I think people use them for lack of a better free alternative. Look inside configure scripts, for example (yecch).
Good old m4. The gnu tools provide autoconf, which generates configure scripts.
If you want something else, you could try Anjuta or kdevelop, or one of the many other IDEs.
> Tools are just one of those things that people will make just barely tolerable to be able to do other work, which is the state of the free tools, right now.
I’d disagree. Yes, there are some awful tools. Conversely, there are some very nice ones, like oprofile; perhaps check out kcachegrind at some point as well. Linux sorely lacks a dtrace alternative, but free development environments aren’t quite as terribly primitive as you make them sound.
I don’ t have undertand well the license type. So i can recompile this software for another unix but i can’ t include it in another software (gpl or othe licensed) and insert algoritm just used, but brand new (mine) yes. Is that correct? (apart english, that is very bad)
Dtrace particularly gaurds against this and is safe for use all the time, no insruction boundry restrictions or anything.
——
dtrace as a tool provides safety against this similar to user space dprobe based tools. the above stuff you quoted specifies how in kernel implementation is supposed to work. this is similar to dtrace in kernel implementation details. not exactly the same but similar