Apple Quietly Fixes DTrace

In January we discussed a blog entry revealing that Apple had "crippled" its DTrace port. As the author notes in a followup post, to say that DTrace had been "crippled" was at least overstated: "Unfortunately, most reactions seized on a headline paraphrasing a line of the post — albeit with the critical negation omitted." In an updated entry, the poster notes that Apple has made good (so we have too): "One issue was that timer based probes wouldn't fire if certain applications were actively executing (e.g. iTunes). This was evident both by counting periodic probe firings, and by the absence of certain applications when profiling. The good news is that Apple has (quietly) fixed the problem in Mac OS X 10.5.3."

Took them long enough

[cibyr]

These sort of concurrency issues are bad enough when they're bug in your *own* code. When it's stuff in other apps producing what appears to be strange behaviour in your own (perfectly fine) code, that's a BIG problem.

This sort of issue wouldn't survive for a week on Linux.

Re:Took them long enough

[morgan_greywolf]

While it might have seemed to some that tinfoil hats were in order (and maybe some might think they still are), it seems to me that this was likely just a bug in Apple's port of DTrace. Does anyone know if they posted (or will post) any patches for DTrace upstream?

Re:Took them long enough

[Anonymous Coward]

But that's exactly what Apple's done with their DTrace implementation. The notion of true systemic tracing was a bit too egalitarian for their classist sensibilities so they added this glob of lard into dtrace_probe() -- the heart of DTrace:

#if defined(__APPLE__)
/*
* If the thread on which this probe has fired belongs to a process marked P_LNOATTACH
* then this enabling is not permitted to observe it. Move along, nothing to see here.
*/
if (ISSET(current_proc()->p_lflag, P_LNOATTACH)) {
continue;
}
#endif /* __APPLE__ */

Re:Took them long enough

[jonwil]

Its clear from the DTrace source from Apple that this is intentional. The OS has a "this app cannot be debugged" flag and they deliberatly made the decision that "cannot be debugged" == "cannot be DTraced"
Most likely they are trying to prevent tracing/debugging/reverse engineering of apps like iTunes and QuickTime that host ITMS DRM content.

Re:Took them long enough

[Anonymous Coward]

Surely you could just recompile dtrace for mac os x without the check though?

Re:Took them long enough

[somersault]

Obviously DRM crackers are incapable of this level of ingenuity (if you live in cuckoo land that is..)

Re:

[flithm]

Not necessarily. If they did their jobs correctly then the "check" wouldn't be in the dtrace app itself. It would be at the operating system level... an app would designate itself not debuggable, then the kernel api calls that dtrace uses to enumerate the list of running apps it can investigate simply wouldn't return the non-debuggable apps.

Although I've no idea if this is the case, or what they've done, I suspect they simply fixed the underlying calls that dtrace uses to report on non-debuggable apps, wh

Re:

[makomk]

Apparently, some of the code required to do so isn't available - you can read and modify the code responsible for the DTrace lockout, but without the rest of the code - just as object files and headers, source code isn't needed - there's no way to replace it with the modified version. (Since DTrace is under the CDDL and not the LGPL, I don't think there's any requirement for Apple to provide the necessary files to replace the code with a modified version.)

Re:

[LordGilman]

You don't even have to recompile dtrace, there's a kernel extension that patches around Apple's code. http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_ATTACH.20080122.html [bikemonkey.org]

Re:Took them long enough

[Lally Singh]

It was apple-specific. They had a "don't debug me" flag that a process could set at startup (to protect DRM). But there was a bug in the interaction of these processes that could cause dtraced processes to take *forever*.

Re:Took them long enough

[powerlord]

This sort of issue wouldn't survive for a week on Linux.

Developer specific issues like this would certainly be fixed quickly under Linux, since it is a developer OS. On the other hand, usability issues that get fixed quickly under OS X, are often left to languor under Linux.

In both cases those features may never be fixed under Windows (or would be broken again after the next "Service Pack" :P )

Re:

[argent]

On the other hand, usability issues that get fixed quickly under OS X, are often left to languor under Linux.

That's an ongoing problem with open source software, even on OS X. Camino, the "usability" oriented Gecko browser on OS X, has years-old issues.

On the gripping hand, Apple still hasn't cleaned up Finder, though I congratulate them for finally ditching Metal. The "Cocoa-ized" Leopard Finder has major regressions (for example, it no longer tracks different views of different folders).

Safari on Windows

Re:

[Crazyswedishguy]

Their passive-aggressive relationship with multiple mouse buttons is a crying shame.

To be honest, to me this seems like a thing of the past. Apple-critics tend to use it as an argument against Macs but really, that was fixed when the Mighty Mouse came out. I would argue even before that, since I was using out-of-the-box (as in drivers already installed) a Microsoft 5-button mouse on my first Powerbook, and could configure all the buttons. If you're working on a Macbook or Macbook pro, I find the "double-finger click" (whatever you want to call it) equally if not more convenient than havin

Re:

[petermgreen]

To be honest, to me this seems like a thing of the past. Apple-critics tend to use it as an argument against Macs but really, that was fixed when the Mighty Mouse came out.
for desktops yes (and as you say you could use a third party multi button mouse before that) thier laptops still come with only one button below the touchpad though.

Re:

[krunk7]

for desktops yes (and as you say you could use a third party multi button mouse before that) thier laptops still come with only one button below the touchpad though.

I've come to prefer this setup in laptops. Most clicking done is left clicking, when I switch to a windows laptop I find myself inadvertently hitting the right click constantly. I prefer the precise control offered by a ctrl+click which is (for me) less prone to accidental clicking. I'm not saying your preference is bad, or that mine is super

Re:

[steeviant]

I can't say I prefer having one button on the trackpad on my PowerBook, but there's another method to right click than the one you mention. You can just tap instead of scrolling with two fingers for a click, no need to touch the mouse button.

Being able to "tap" a right button with two fingers would be a valuable feature on PC laptops (I virtually never touch the trackpad button), but a right mouse button on the MacBook (Pro) would be of more value IMHO since they are hardware compatible with Windows and "ri

Re:

[argent]

To be honest, to me this seems like a thing of the past. Apple-critics tend to use it as an argument against Macs but really, that was fixed when the Mighty Mouse came out.

The mighty mouse is exactly the kind of passive-aggressive **** that I'm talking about. The Mighty Mouse does not allow chording, and to reliably get right clicking out of it I have to hold my hand in an uncomfortable position tat severly aggravates my RSI. I use a Microsoft wheel mouse, the two-button-plus-wheel cheap mouse, and it works

Re:

[krunk7]

I've never used a one button mouse with mac. I've never used the bundled mighty mouse. I've never used the bundled mouse with OEM windows machines (hate them, very un ergonomic and give me carpal).

In this sense (using a 3rd party multi-mouse button with my desktop purchase), nothing has changed from windows to osx.

For my thoughts on the one button laptops, I prefer it. Some folks like one model of car, some like others. I wouldn't say it's because one car manufacturer has a hatred for features in the ot

Re:

[argent]

For my thoughts on the one button laptops, I prefer it. Some folks like one model of car, some like others. I wouldn't say it's because one car manufacturer has a hatred for features in the other. It's just a matter of options/choice/preference. Choice is good? amiright?

When I can buy OS X retail and install it on a Thinkpad I'll be happy to agree with you.

Since that's not going to happen, where's the choice?

Re:

[Dog-Cow]

When I can buy a Focus with the interior of a Jaguar, your analogy might make sense.

Since that's not going to happen, what the hell are you talking about?

Re:

[argent]

I think you understand exactly what I'm talking about.

The message I was responding to was talking about having different kinds of input devices on laptops being good because it gives you a choice.

An operating system is not just bucket seats and woodgrain steering wheels. Windows is not an option (don't even think about arguing with that one) and until I can get the same variety of commercial desktop software for Linux as I can for OS X then Linux is not an option (don't even start on running Windows in a VM

Re:

[Dog-Cow]

I've been working on the Macbook Pro since it's been out, and it doesn't work worth a damn for me.

You should go to an Apple Store and have the local Genius teach you how to use it. It's so simple, even a slashdotter should be able to figure it out.

Re:

[PitaBred]

...really? It's active by default under Windows and Linux. I'm 100% sure on Linux, not as sure about Windows since I haven't used it in quite a while...

Re:

[PitaBred]

Most newer laptops are, I'd think. My Compal HGL30 and my Lenovo Thinkpad T61 both definitely do it, not sure about other models.

Re:

[argent]

I hope you realize that two-finger click isn't active by default and you need to activate it in the system preferences.

Yes. It "doesn't work for me" means "I do not find it an adequate replacement for a second button. I need to be able to activate the contextual menu without tapping the touchpad, because it's too easy for me to jiggle the mouse in the process whether I'm one- or two- finger tapping.

Re:

[JonathanBoyd]

If you already have a finger on the pad (which you presumably do as a result of having moved the pointer to where you want to click), placing a second finger on the pad doesn't jiggle it at all, so you can right-click in safety by tapping he button with your thumb. Even if you don't have a finger on the pad, plonking two down at the same time shouldn't result in any pointer movement and even a bit of a delay between the first and second hitting rarely produces movement and even then only by a couple of pix

Re:

[argent]

If you already have a finger on the pad

I don't rest my finger on the pad, because any subsequent motion of my hand causes small movements, and because I have to make muliple strokes on the pad to move the mouse any distance so I am in the habit of stroking the pointer around and only touching the pad when I'm actually moving the pointer.

Even if you don't have a finger on the pad, plonking two down at the same time shouldn't result in any pointer movement

I find that plonking down *one* at a time can cause mo

Re:

[JonathanBoyd]

I don't rest my finger on the pad, because any subsequent motion of my hand causes small movements, and because I have to make muliple strokes on the pad to move the mouse any distance so I am in the habit of stroking the pointer around and only touching the pad when I'm actually moving the pointer.

Ok. Though I would have thought that most of the times when you want to click, it would come immediately after movement, so your fingers would already be there. I can see how it would be an issue though if ther

Re:

[argent]

The point is, you can easily use a Microsoft wheel mouse on a Mac.

Indeed, there isn't even a clue-anticlue explosion when it's plugged in. Though you couldn't under OS 9, and Apple still doesn't ship an actual two-button mouse, and application support for the right button is still not universal (which I elaborate on in another comment in this thread).

your Windows PC

You take that back!

have you activated multiple finger scrolling and clicking?

Yes, I have already explained this in far more detail in another f

Re:

[99BottlesOfBeerInMyF]

Their passive-aggressive relationship with multiple mouse buttons is a crying shame.

I find their stance on mouse buttons to be ideal. As a usability expert, I can assure you misuse of secondary mouse buttons is one of the most common usability problems, even for more advanced users, although they often do not consciously note it. For novice users, a single mouse button is by far preferable. For trackpad users, both novice users and power users complete tasks faster using two-finger taps or chording... with only midrange users having issues. Standardizing one one button as the requirement

Re:

[argent]

As a usability expert, I can assure you misuse of secondary mouse buttons is one of the most common usability problems,

Argumentum ad verecundiam. I've been seeing people make claims like this for almost 25 years now, and I have yet to see a single credible study that supports it.

Single button mice are more "demo friendly". That's it.

* Applications are *not* as consistent as you claim. There are many actions even in Apple's apps that are only available through the contextual menu, or through magic chords.

* T

Re:

[NMerriam]

Argumentum ad verecundiam. I've been seeing people make claims like this for almost 25 years now, and I have yet to see a single credible study that supports it.

Anyone who has spent a day answering phones on a tech support line can confirm that mixing up mouse buttons is a common issue.

"right click on the icon"
"double click?"
"no, ma'am, click the right button on your mouse"
"how do I know which button is the right one?"

Re:

[99BottlesOfBeerInMyF]

Argumentum ad verecundiam. I've been seeing people make claims like this for almost 25 years now, and I have yet to see a single credible study that supports it. Single button mice are more "demo friendly". That's it.

What are you talking about? Have you ever performed a usability study on a modern computer? There is always at least one person messing up and hitting the wrong button. I once thought I was going to get away without that problem when testing an interface for network security experts, but sure enough one of the top guys at AT&T (a really bright guy by the way) who was helping us test accidentally clicked the wrong button while trying to access a menu. This is an absurdly common issue. To claim it has n

Re:

[argent]

Have you ever performed a usability study on a modern computer?

No, but I've read as many of them as I can get my hands on, and have found none of them credible. It's easy to see the errors: you'll find them comparing mockups of user interfaces that never actually got implemented, or user interfaces that are clearly designed to make one or another operation work better, or have taken the interface the experimenter doesn't like to extremes (like the "five button mouse"). I have, for the past quarter of a cent

Re:

[99BottlesOfBeerInMyF]

Have you ever performed a usability study on a modern computer?

No, but I've read as many of them as I can get my hands on, and have found none of them credible.

So you're claiming the entire field of scientific research into usability is not credible, and the alternative you're proffering, is your own personal opinion backed up by no data whatsoever? I've got to tell you, that's not very persuasive.

I have, for the past quarter of a century, rarely even had any user interface experts provide an example of a study other than Apple's original flawed work.

Have you considered actually going to HCI conferences, subscribing to the journals, or just reading the academic papers published online. There are a lot of rigorous usability studies, usually testing a particular interface and looking for problem tasks/workflows.

I'm an advanced user. I have decades of experience with Macs and just about every other user interface that uses a mouse and windows, including every version of Mac OS, the Lisa, and all three of the GUIs Xerox developed on the Dorado and Dolphin boxes. I am still discovering magic keys in Apple applications by means of word-of-mouth and google.

Re:

[argent]

So you're claiming the entire field of scientific research into usability is not credible

No, I'm claiming that I haven't had anyone provide a credible study. There may be some, but they all seem to be locked up somewhere.

Most people respond by asserting that I am rejecting an entire field of scientific research, but decline to actually provide a reference to a single study to support this assertion.

Have you considered [...] just reading the academic papers published online.

Well, hey, you want to be an excep

Re:

[99BottlesOfBeerInMyF]

* Applications are *not* as consistent as you claim. There are many actions even in Apple's apps that are only available through the contextual menu, or through magic chords.

Really. Care to cite an example? I know of only two applications on OS X that are exceptions to this rule, one of which is an abysmal custom interface trying to exactly mimic the Windows version and the other is a high end graphics application that specifies users must have a multi-button mouse to use it. I'll give you a hint, look in the regular menus.

The menu bar can be up to 1,000 pixels away from the current position of the mouse. Sure, you can increase sensitivity, but then you lose pixel-level control of the mouse pointer due to your hand tremors.

Yeah, selecting things from the regular menus when you can use a right-click context menu can be slow, which is why it is nice to have both options. The point of standardizing on one button is it forces developers to put them in the regular menus, even if they also put them in the the right-click context menu as well.

The reason the above is advantageous is for all the novice user who don't properly use the second mouse button and for all the people using alternative interfaces that don't have a second

PROTIP: Press Shift+F10 for a context menu

[tepples]

If you're blind and using an audio interface and a function is only in the right-click context menu, well you generally can't use that program at all.

Most applications for Windows allow the user to focus a control, then hold Shift and press F10 to open the control's context menu. Many keyboards manufactured since 1996 have a special key that also opens the focused control's context menu, located between the right meta key and the Ctrl key.

Re:

[tepples]

The reason is because the Apple menu bar is flush with the top of the display, so it is effectively infinitely tall.

This is true if you have the menu bar on the top display.

You can slam the mouse over there at high speed with little need for precision.

Even if you have to move the mouse up, pick up the mouse from the mouse pad, move the mouse down, place the mouse on the mouse pad, and then move the mouse up again? Fitts's law [wikipedia.org] assumes O(log(d/w)) to move d pixels toward a target of size w pixels, but above some distance, this becomes O(d).

A Windows menu bar, on the other hand, is only a few pixels tall.

As is each menu item. Under Windows or many recent X11 environments, I can move the mouse in the general direction of the menus, press Alt+E to open the Edit me

Re:

[wootest]

Finder was only "Cocoa-ized" to the point where Cover Flow is a Cocoa view. The rest is Carbon, it's just mostly a lot faster. The regression is actually, if you're to believe Apple design documents, a 'feature' since the view is now global. I guess it does solve the nearly impossible-to-predict mess that was there before to determine the view for a particular folder, but only in the same way that blowing up a car with a flat tire solves having a car with a flat tire. And for fucks sake, who decided we only

Re:

[init100]

On the other hand, usability issues that get fixed quickly under OS X

One area where they haven't fixed serious usability issues is in Spaces. They updated the behavior in 10.5.3, but I wouldn't call that an improvement. Until they fix Spaces to work better, I'd consider it a case of shipping beta-quality software.

Re:

[prockcore]

On the other hand, usability issues that get fixed quickly under OS X, are often left to languor under Linux.

I have only one thing to say on that: FTFF.

Re:

[somersault]

How is that a 'usability issue'? It's a security issue.

Re:Took them long enough

[somersault]

Fair enough, though 'usability' generally refers to interface design, I'd definitely still refer to it as a security issue, which I'd say is more important than 'usability', though successful software companies like MS and Apple don't seem to agree!

Re:

[Ephemeriis]

These sort of concurrency issues are bad enough when they're bug in your *own* code. When it's stuff in other apps producing what appears to be strange behaviour in your own (perfectly fine) code, that's a BIG problem.

This sort of issue wouldn't survive for a week on Linux.

If you read the original story, which this one is an update to, then you'll see that there are no bugs - only features.

Apple intentionally disabled DTrace on some software.

You can actually take a look at Apple's DTrace source.

Re:

[init100]

Apple intentionally disabled DTrace on some software.

Yes, but did they intend to disable tracing of all applications running concurrently with a non-traceable application? Which is what they did.

Re:

[kscguru]

Wishful thinking.

• Linux STILL doesn't have DTrace, they use kprobes(?) instead because somebody claimed it was almost as good (DTrace users know the Linux equivalent is woefully inadequate and needs several years to even reach feature parity). Not-Invented-Here syndrome.
• Look at kgdb, which Linus finally merged parts of after many years. Linux feels developers shouldn't be using debugging tools on the kernel. Any bets on whether he would merge DTrace at all?
• Even if Linux had DTrace, this fix would be a

Good news

[Anonymous Coward]

This was blogged about some days ago, but I'm glad that the news is out.

DTrace is used in all sorts of interesting ways. On the Belenix project, for e.g., we've sped up the LiveCD boot enormously, and this innovative use of DTrace is now part of the Distro Constructor Toolkit at opensolaris.org.

On my Dell D620, Belenix boots in about 3 and a half minutes (with KDE), while Ubuntu 7.10 boots up in about 8 minutes.

-- Sriram
http://www.belenix.org/
http://dynamicproxy.livejournal.com/

Re:

[Constantine XVI]

The better question is: how bad is your D620 that Ubuntu takes 8 minutes to load? I've never seen longer than 5, and that was on a Celeron 633 w/ 96MB of RAM.

Re:Good news

[Anonymous Coward]

That's just sad. You shouldn't flash those numbers in public.

Boot times...

[argent]

I'm sick of boot times measured in minutes.

What is this, 1980?

Re:

[rekoil]

Don't forget he's talking about LiveCD boot times, not boot times from hard disk...

CD vs Floppy

[argent]

They should still be able to beat 1980 floppy boot times using a CD-ROM.

Yes, I know they're doing a lot more than in 1980.

That's the problem. How much of what they're doing is necessary?

Re:

[laffer1]

I don't think you realize how big gnome/kde actually are.

Re:

[argent]

I don't think you realize how big gnome/kde actually are.

I don't think you're looking at the problem right. :)

"How big Gnome/KDE are" is part of it.

Re:

[laffer1]

Well people expect different things from a live CD than an DOS boot floppy.

Now boot media has to support networking, and include as a full desktop environment. Imagine trying to boot dos + WFW 3.11 on floppy, plus a dialer and netscape. Not to mention people used to tweak boot floppies for their systems and not load extras.

Re:

[argent]

Well people expect different things from a live CD than an DOS boot floppy.

What does a Live CD need to do *at boot* that an HP Integral or Amiga 1000 don't? They all boot to a GUI with windows, icons, a desktop, and so on.

Imagine trying to boot dos + WFW 3.11 on floppy, plus a dialer and netscape.

I don't have to imagine it, I've done it. Pointing to a REALLY bad implementation that (by the way) Gnome is doing a really BAD job of emulating is hardly the way to convince me that the bloat of Gnome and KDE is j

Re:

[laffer1]

You're misinterpreting what I'm saying. I agree that Gnome and KDE are too bloated. Most software is these days. People are taught that memory and disks are cheap so it's OK to code badly. My point is that people expect more from a "boot disk" now than they did 10-20 years ago. So any benefit from new hardware is lost on the extra cruft we get along with it. Many gnome applications are written in python now. I find that insane.

Most people do NOT tweak live CDs. So comparing them doesn't make sense.

Re:

[argent]

My point is that people expect more from a "boot disk" now than they did 10-20 years ago.

And I'm not talking about "how much stuff do you put on the disk". It doesn't matter if the CD image is 2M, 20M, or 200M, that's not going to change how long it takes to boot!

I'm talking about "how long does it take to boot to the GUI".

As a baseline, let's say the windows 98 se boot floppy.

Let's not.

Windows is also too bloated.

I bet it's closer than you think.

The fact that your CD boots as slowly as a floppy means CD'

Re:

[laffer1]

"I'm talking about "how long does it take to boot to the GUI".

yeah. Well it's not a 1:1 relationship, but more on the disk does mean it takes longer. I don't see why you can't connect what I'm saying to what you're saying. It takes time to detect and setup hardware during boot. It takes time to init a display, setup a login or window manager, etc. If we're talking about boot to gui time, dos doesn't matter. Mac OS matters. NeXTSTEP matters. THings that existed during that time period which had gui

Re:

[argent]

If we're talking about boot to gui time, dos doesn't matter.

Who the hell is talking about DOS? I certainly aren't.

Amiga 1000: 1985
HP Integral: 1985

THings that existed during that time period which had guis. ... and BOOTED OFF FLOPPIES.

Like the Amiga 1000 and HP Integral.

I have a NeXT, and I can tell you it doesn't boot all that fast, especially with OpenSTEP 4.2.

I had a NeXT, too. Gave it to someone who wanted one and whose wife didn't object to bringing it home, when I left ABB.

It was running Display Posts

Re:

[Dog-Cow]

Amiga 1000.
HP Integral.

Neither of which did extensive hardware discovery. A LiveCD (and the Windows 98 boot disk) doesn't know what hardware it's going to find. It probes for everything it has drivers for.

That takes time. Period.

Re:

[argent]

You only need to probe for legacy hardware. Any hardware since, oh, sometime in the '90s should have already been enumerated during POST.

Re:

[swimmar132]

I'd say a graphical user interface, word processor, web browser, programming/debugging tools, all that should be necessary for a modern live CD.

Re:

[argent]

You don't need to load a word processor, web browser, or programming and debugging tools during boot.

You do need to load the GUI, yes.

If you cant boot to a GUI from a CD faster than an HP Integral (running System V UNIX on a 68000!) could from a floppy, there's something wrong with your GUI.

That's running UNIX, mind. I'm not expecting you to beat an Amiga 1000, though that *was* loading firmware as well from the kickstart, but you should at least be able to do better than a mid '80s UNIX box.

Good going apple!

[YeeHaW_Jelte]

Your evilness index has just dropped from 45.8 to 45.3

Keep up the good work!

Re:

[sootman]

My first thought was that the headline was misleading. "Fixes" implies fixing existing bugs, like when Apple fixes things in KHTML. The proper headline should have been "Apple quietly un-fucks-up DTrace."

Re:

[shutdown -p now]

What's the Google's one?

Microsoft, I would assume, is +INF. No matter what they do, they're pure evil personified, at least on /.

Quietly, quietly

[gonerill]

What is the connotation of "quietly" supposed to be in stories like this? (Not just with Apple.) It seems like a weasel word. Is the intention to give the impression that Apple embarrassedly corrected themselves, or that they were forced to give into pressure from the developer community, but don't have the cojones to admit it, or what? Because, anyone honestly expecting something other than a "quiet" fix is deluded. Is a bug fix in DTrace supposed to get a slide at a Stevenote or something?

Re:Quietly, quietly

[stewbacca]

"Quietly" infers that the slashdot crowd should get credit, where no credit is due, as if our overwhelming numbers and sheer pressure forced Apple to change. Unfortunately, in the real world, we are such an insignificant demographic, that any changes are thus labelled as being done "quietly".

Re:Quietly, quietly

[timeOday]

Looking at the blog entry, no mention is made of an apple announcement at all; this blogger infers it is fixed based on what he would expect to see. What better definition of "quietly fixed" do you want?

From a developer standpoint, this is a very bad thing apple did. Understanding what's going on and getting stuff to work is hard enough without zombified debugging tools that lie to you.

Re:

[Wooky_linuxer]

Yes, because it is not a bug fix; it is a feature fix, if such a thing exists. The previous design was intentional. So, yes, if someone changes a design decision in a software I buy, I'd like to know why they did it - and in this case I'd like to know why it was there at the first time. I wasn't expecting a big announcement but a single line in OS X update page saying something along the lines of "revert DTrace to original behavior due to ___ " would do.

Re:

[x_MeRLiN_x]

Ummmm.. no. Windows Service Packs are comparable to point (e.g. 10.1 as opposed to 10.0) releases of OS X.

Microsoft patches are almost always* accompanied with installation instructions, affection products and possible caveats. At no point do they market bug fixes. Service Packs are made up of hundreds of patches - not one.

*Slashdot has in the past been very keen to point out Microsoft patches ushered in without notifying users.

Get a grip.

"Quietly"

[Plantain]

What did you want, a friggin' parade?

Jeez, give a fruit a break.

DTrace 2.0: Now 30% Less Crippled!

[NoCowardsHere]

Apple designed their port of DTrace so that any program could "opt-out" of profiling if the developers are concerned about reverse-engineering. An unintended consequence of this was that it sometimes broke profiling of other apps while those apps were running. They've fixed that bug in their implementation of crippling, but that doesn't mean they've un-crippled it.

It's a big step forward, because now at least developers can properly profile their own code. However, one of the purposes of DTrace is to profil

They haven't "fixed" it at all

[gleffler]

There are still several apps to which you can not attach DTrace, such as iTunes. The issue described in the first blog post hasn't been corrected, you can still set NOATTACH and your process is then untraceable. (Not that shitty movie, but you know what I mean.)

The issue isn't (really) that timer counts are wrong, but instead, the far more interesting thing is that there are "special" processes that you can't touch and everyone is now suddenly OK with that because the timers count correctly.

Re:

[Mr2001]

Apple, I think, has had a relatively non-evil position on DRM: do what they have to do while gently pushing folks toward free formats.

They don't have to do anything to help DRM. Look at Linux: it works just fine without kernel support for DRM, doesn't it?

Further they've created a protection scheme that is as pro forma as you could imagine.

There's still no way to play a DRM'd Apple video file outside of iTunes/iPod/AppleTV. That's significantly more restrictive than, say, a DVD.

Re:

[Mr2001]

Right, that's why you see so much content available from record and movie companies available on Linux.

Yes, I hear Amazon and eMusic have plenty of MP3s for sale.

Totally. And there's absolutely no DRM on a DVD player

There basically isn't anymore, since CSS is such a joke. But in any case, it's undeniable that a DVD is less encumbered by DRM than an iTunes video.

But surely this was posted by a slashdot-focused eliza program -- no human is this naive.

Hmm, maybe. But it looks like your response was written by an Apple investor; no one else would be so eager to make excuses for them.

Good news doesn't sell

[snowwrestler]

The previous discussion [slashdot.org] generated hundreds of posts within a few hours, and topped out at 476. This one is at 60 comments after 3 hours and will be lucky to break 100. If you've ever wondered why Slashdot posts flamebait stories, there's your answer. "If it bleeds it leads."

Re:

[account_deleted]

Comment removed based on user account deletion

Re:

[somersault]

True, if not for the fact that it's not a bug but rather the intentional behaviour of Apple's version of DTrace. What other reasons do you have? I'm very happy with OSX for home use. Issues like this don't bother me because I'm not trying to reverse engineer the DRM in iTunes - in fact I don't even use iTunes, I use VLC.

Re:

[jeiler]

Don't blaspheme, AC. Microsoft is Teh Evil (TM).

Re:

[bytesex]

Oh I don't know - betting the shop on C# and bringing the spec under certification ? Just my first thought.

Re:

[Dog-Cow]

MS did nothing of the sort. They bet on .Net, which is most definitely not a public standard.

Re:

[antifoidulus]

Don't use xcode?

Seriously, unless you are developing Cocoa(or Carbon) apps, there is very little reason to use XCode. There are better free software programs out there for writing c++ code, not to mention you could always just call good ol' gcc on the command line....

Re:Mac's Suck

[mwlewis]

You must be joking. Have you ever written a project that had more than 5 C++ files? I work on projects that have dozens -- if not hundreds -- of different files, organized into multiple different directories, with many different library dependencies and different configuration options. Manually calling gcc is simply impossible, unless I want to waste half a day every time I need to compile something.

WTF? It's called a makefile. "Manually invoking" gcc goes something like this:

$ make

Re:

[keytoe]

So I should write a program that knows how to compile my program then? This is an improvement over Xcode how?

Re:

[mwlewis]

If you like XCode, and don't see the need to ever not use it, then it's probably not an improvement. And the people using MSVS probably aren't building makefiles, either. So what? But it's an improvement over "manually invoking" gcc, which is what the AC was talking about. It's also not tied into a specific IDE, which may or may not be important to you.

In any case, it has nothing to do with the OP's issue...

Re:

[chthonicdaemon]

Have you ever seen the linux kernel sources? Many, many files. Or the emacs sources, or the gcc sources? Many people working/leading these projects use vi/emacs and make. They are not dumb. Many of them have tried the alternatives and gone back to tools that do what they want. I can honestly not believe that any one development tool can be optimal for all programmers simultaneously. So if you dig Xcode, that's fine -- many people do. Many people like a good text editor and a Makefile and really don'

Ahhh... make and makefile????

[mario_grgic]

I work with hundred thousand files and compile from the command line (a single command even):

$ make

does the trick at the top directory. Yes, that means you have to maintain the makefile but that's not that hard to do and is not done daily or even weekly.

Re:Mac's Suck

[Plantain]

Lifted from http://developer.apple.com/qa/qa2001/qa1118.html [apple.com] because I know no one will RTFA

Q: I'm trying to link my binary statically, but it's failing to link because it can't find 'crt0.o.' Why?

A: Static linking of user binaries is not supported on Mac OS X. Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X. Instead, dynamic linking is supported (linking against crt1.o automatically instead of looking for crt0.o, for example).

We strongly recommend that you consider the limitations of statically linking very carefully, and consider your customer and their needs, plus the long-term support you will need to provide. Apple provides support and attempts to insure complete compatibility through the published APIs, but cannot insure that compatibility in a statically linked project. Any change to Mac OS X, in a system update, security update, or major revision, may break statically linked code.

If your project absolutely must link statically and need crt0.o, you can get the Csu module from Darwin and try building crt0.o statically. Please bear in mind that you must then clearly specify to your customers the compatibility risks involved in installing a product that relies on statically linked code.

Re:

[mzs]

The the gp was a troll. For what he/she wants to do you can just copy the archive you need and then do cc foo.a bar.o and then ./a.out and it runs fine. I do it all the time to make big static binaries that run on vanilla OS X.

Re:

[dadragon]

That's not really a static binary. It's statically linked to one library, and not the system library. The system library can't be statically linked in Mac OS X for reasons given in another branch of this thread.

Re:

[Guy Harris]

Static linking of user binaries is not supported on Mac OS X.

And, to the extent that it's supported on Solaris, there's no guarantee that a binary statically linked in Solaris N will run correctly in Solaris N+1.

OS X's and Solaris's ABI's are defined in terms of calls to routines in dynamically-linked libraries, not in terms of system calls.

There may well be other UN*Xes that work the same way. I have the impression that's how Windows works, as well. This allows the implementation of routines in those

Re:Mac's Suck

[Halo1]

Write a simple c or c++ hello_word program. Then try to compile and link it with Xcode using -static. It won't work b/c Apple has fucked-up ld.

It has nothing to do with ld. The reason it doesn't work is that there is no static version of libc (aka libSystem) on Mac OS X. And the reason for that is that on Mac OS X, libc is the lowest level publicly supported system interface.

There are of course system calls (both BSD-style and Mach-style ones), but they are undocumented and can change from one Mac OS X version to another (even between minor system updates). The reason is that Apple wants to have and keep full freedom in changing the systemuser space interface at any time it wants whenever that's convenient for whatever reason (performance, security, getting rid of legacy cruft, ...).

So if you'd statically link a program, it would be linked to a particular libc version which in turn would use the system calls as they work on the particular version of Mac OS X this libc version was compiled for. The end result would be that your program would only be guaranteed to function correctly on that particular OS revision.

libc's interface on the other hand is kept backwards compatible between OS revisions, so as long as you dynamically link against it, your program will work fine on pretty much any OS version out there (except if you use APIs which didn't exist yet in older versions).

This is more or less the opposite case as on e.g. Linux, where glibc breaks binary compatibility every other full moon (so you need to distribute different binaries for different glibc versions if you want to link dynamically to it), but the kernel's system call interface is pretty much guaranteed to remain backwards compatible for a very long time (so statically linked binaries are generally much more portable across distributions â" the downside is that you then should link everything statically because installed dynamic libraries may rely on features provided by a newer glibc than the one you statically linked, and in case of e.g. a KDE or GNOME app you'd end up with immense binaries).

Re:

[autophile]

So.... I guess this won't be the Year of the Linux Desktop?

Re:

[Johnny Mnemonic]

using reason and facts will just confuse them. Macs suck this week, please read the memo.

Re:

[vijayiyer]

No they haven't. They just didn't provide the static libc. If you install the static libc, you can compile static binaries. What does that have to do with ld?

Re:

[GrahamCox]

Write a simple c or c++ hello_word program

On the other hand, try this. Create a new project in Xcode. Open mainmenu.nib in Interface Builder. Drag an NSTextView to a window, save, compile, run. Result - a complete functional word processor. You can even type "hello world" into it if you want.

Fuckwit.

Re:

[nuzak]

> Unless OS X supports hardware-enforced signed binaries, of course. Which it doesn't.

It could. Every mac has a TPM module. They just don't use it yet (and likely won't for a long time if ever)