×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apple Quietly Fixes DTrace

kdawson posted more than 5 years ago | from the understating-it dept.

OS X 144

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

144 comments

Took them long enough (2, Insightful)

cibyr (898667) | more than 5 years ago | (#23745587)

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 (4, Insightful)

morgan_greywolf (835522) | more than 5 years ago | (#23745633)

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 (5, Informative)

Anonymous Coward | more than 5 years ago | (#23745851)

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 (5, Informative)

jonwil (467024) | more than 5 years ago | (#23745927)

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 (5, Insightful)

Anonymous Coward | more than 5 years ago | (#23746169)

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

Re:Took them long enough (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#23746331)

Surely you must be joking!

Re:Took them long enough (5, Funny)

somersault (912633) | more than 5 years ago | (#23746453)

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

Re:Took them long enough (1)

flithm (756019) | more than 5 years ago | (#23748701)

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, while still leaving those apps unable to be debugged.

Re:Took them long enough (1)

makomk (752139) | more than 5 years ago | (#23751007)

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:Took them long enough (5, Informative)

Lally Singh (3427) | more than 5 years ago | (#23746133)

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 (5, Interesting)

powerlord (28156) | more than 5 years ago | (#23745667)

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:Took them long enough (-1, Offtopic)

stewbacca (1033764) | more than 5 years ago | (#23745963)

Modded insightful? I found it to be funny as hell! Thanks for the good chuckle this morning.

Re:Took them long enough (0, Interesting)

Anonymous Coward | more than 5 years ago | (#23746333)

On the other hand, usability issues that get fixed quickly under OS X
You mean like your machine getting pwned by a malicious iCal file? Is that fixed yet? You know, the vulnerability that was reported to them months and months ago?

Re:Took them long enough (1)

somersault (912633) | more than 5 years ago | (#23746541)

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

Re:Took them long enough (1, Interesting)

Anonymous Coward | more than 5 years ago | (#23748047)

For example, I can't use Mail.app because it has this bug where it automatically sends events to iCal, even if both are set up to not exchange events. So if I get an email with a malicious file, it'll compromise my system. I have to use some other mail reader until they fix it.

Unfortunately, I need to follow other sources to find out when they fix it, because Apple won't say when they've fixed it. They will include a vague line something like "Improved reliability of iCal".

Usability, to me, means you know what's going on. Hiding all the details of everything from your customers so they can't make informed decisions is not usability.

Re:Took them long enough (4, Informative)

somersault (912633) | more than 5 years ago | (#23749519)

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:Took them long enough (1)

argent (18001) | more than 5 years ago | (#23746637)

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 has a long way to go.

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

They haven't had a decent keyboard since Jobs took over.

And they badly need a new input handler and API. They could call it "Core Input", and have applications register with it to receive events like "menu request" or "next page" instead of having to track mouse and keyboard actions and having three hundred different ways of saying "I want to use control-meta-cokebottle-left-fish as page down" in as many different preference panes. They could even hook it in to Automator and Applescript...

Re:Took them long enough (3, Informative)

Crazyswedishguy (1020008) | more than 5 years ago | (#23747203)

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 having a right-click button.

I know Macs aren't perfect, and there are other issues with them, but is the "passive-aggressive relationship with multiple mouse buttons" really still a reality?

(Obligatory disclaimer: I am, admittedly, somewhat of an Apple fanboi, but I do agree that Macs have their flaws as well. I just tend to prefer Apple products for design and usability - they fit my needs. I made the switch about 5 years ago)

Re:Took them long enough (1)

petermgreen (876956) | more than 5 years ago | (#23747671)

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:Took them long enough (1)

krunk7 (748055) | more than 5 years ago | (#23748009)

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 superior. But it would appear that it is a preference. I've heard this from many switchers as well. So I'm not unique in this. As far as the desktop, I've never used a one button mouse with osx. Nor have I noticed any differences in functionality from windows.

Re:Took them long enough (0, Funny)

Anonymous Coward | more than 5 years ago | (#23748801)

Mac users- unable to differentiate between the right and left mouse buttons. They should put that in the next "I'm a Mac, I'm a PC commercial".

Re:Took them long enough (1)

Crazyswedishguy (1020008) | more than 5 years ago | (#23750299)

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.
Note my comment above:

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 having a right-click button.
Essentially, on Apple laptops, if you put two fingers on the touchpad and click the button below it, that's a left click. In my personal opinion, this is more convenient than having two buttons which you sometimes accidentally click (my work computer is a Dell, it definitely happens).
In a similar fashion, the touchpad also allows vertical and horizontal scrolling by dragging two fingers. This means you're not wasting touchpad real-estate with the scroll areas on the side of the touchpad.
It's a matter of opinion, but I prefer the way that Apple does it now. (but it's a relatively recent improvement) YMMV

Re:Took them long enough (1)

Crazyswedishguy (1020008) | more than 5 years ago | (#23750319)

Essentially, on Apple laptops, if you put two fingers on the touchpad and click the button below it, that's a left click
And by left, I mean right.

Re:Took them long enough (1)

ORBAT (1050226) | more than 5 years ago | (#23750845)

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.
Did you actually read what parent said? The laptop trackpads implement right-click as a gesture (tap with two fingers instead of one) so your point is pretty much moot. I have a MacBook and I never use the "regular" button, but tap or "double-tap" the trackpad when I click.
Can we just forget the "LOLZ U CANT RIHGT CLIK ON A MAC" crap and move along?

Re:Took them long enough (1)

argent (18001) | more than 5 years ago | (#23747787)

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 far better than any mouse Apple has produced.

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 having a right-click button.

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

Is the "passive-aggressive relationship with multiple mouse buttons" really still a reality?

Not only reality, but what you're pointing to are the symptoms.

Re:Took them long enough (1)

krunk7 (748055) | more than 5 years ago | (#23748075)

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 other. It's just a matter of options/choice/preference. Choice is good? amiright?

Re:Took them long enough (1)

confu2000 (245635) | more than 5 years ago | (#23748153)

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 having a right-click button.

I've been working on the Macbook Pro since it's been out, and it doesn't work worth a damn for me.
I hope you realize that two-finger click isn't active by default and you need to activate it in the system preferences. I have a first-gen Macbook Pro and it works fine for me along with two-finger scrolling.

Re:Took them long enough (1, Informative)

PitaBred (632671) | more than 5 years ago | (#23748705)

...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:Took them long enough (1)

Crazyswedishguy (1020008) | more than 5 years ago | (#23751033)

Really, are there actually Windows laptops with multitouch touchpads, i.e. multiple-finger tapping, clicking or scrolling? I don't know of any, but it might be recent development I've missed.

Re:Took them long enough (1)

argent (18001) | more than 5 years ago | (#23750009)

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:Took them long enough (1)

Crazyswedishguy (1020008) | more than 5 years ago | (#23750673)

I use a Microsoft wheel mouse, the two-button-plus-wheel cheap mouse, and it works far better than any mouse Apple has produced.
The point is, you can easily use a Microsoft wheel mouse on a Mac. I've had Microsoft (or other brand) mice for my laptops for several years. I used to have a 5-button mouse on my first mac, it worked great.
Personally, I agree with you about the Mighty Mouse. I don't like using it, I haven't gotten one. It looks pretty, and some people swear by it, it's not for me.

Macs support multiple mouse buttons just as well as any PC I've ever had or seen, and most of the drivers already come installed. So I would still challenge your assertion that there's a passive-aggressive relationship with multiple mouse buttons. They maybe haven't built a mouse that you like, but it works absolutely great with, I believe, just about any third-party mouse you're using on your Windows PC.

As for using your Macbook Pro, have you activated multiple finger scrolling and clicking? Most comments I've read either say it's as good or it's better than two buttons below the touchpad. It's not on by default though, so if you haven't already enabled it, just go in your system preferences and give it a try.

Re:Took them long enough (2, Informative)

99BottlesOfBeerInMyF (813746) | more than 5 years ago | (#23747501)

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 for developers to target also improves overall usability. It means if you are using an alternate input method like a stylus, voice interface, handicap interface, or if you are scripting actions within an application, all functions are accessible in the same, standard way, with no functionality exclusively available to users that can easily access a second mouse button. This also means the second mouse button functionality can be customized by the user, since it is not required to operate any application. That means in my text editor on OS X I don't have useless option in the context menu brought up by the second button (as is the case in Wordpad in WinXP). Instead I assign useful items to that context menu, like a service for auto-replacing line endings. Basically, I think you're way off when it comes to the multi-button mouse thing. The "might mouse" is an ideal new mouse for home computers with multiple users as it is the first I know of that lets software decide if the mouse is multi-button or single button based upon the user account. Apple has its share of usability problems, but their practices with regard to mouse buttons are not one of them. Mostly it is just Windows users complaining because it is different or people who don't actually use OS X regularly complaining about what they assume would be a problem.

Re:Took them long enough (2, Informative)

argent (18001) | more than 5 years ago | (#23747681)

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.

* These magic chords, the alternate mechanisms for replacing the context menu in Mac OS, are not "discoverable". I've been using the Mac almost as long as it's been out... my first Mac was the original 128K Macintosh, I'm definitely a "power user", and I'm still discovering new command-option-shift-double-click combos.

* Using contextual menus does not prevent user configuration.

Mostly it is just Windows users complaining because it is different or people who don't actually use OS X regularly complaining about what they assume would be a problem.

Argumentum ad hominem, too. Not guilty. I use OS X regularly, I've used Macs for almost a quarter of a century. OS X is my primary desktop.

Re:Took them long enough (2, Funny)

NMerriam (15122) | more than 5 years ago | (#23748167)

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:Took them long enough (1)

99BottlesOfBeerInMyF (813746) | more than 5 years ago | (#23748257)

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 never been demonstrated in a credible study either shows complete ignorance of the topic at hand or some bizarre selection criteria for said studies.

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

These magic chords, the alternate mechanisms for replacing the context menu in Mac OS, are not "discoverable".

True, they are not easily discoverable, but that is only one part of usability. Novice users don't need to discover them. Advanced suers have no problem figuring them out quite quickly. The only people at risk are those who want to be more advanced, but are both too cheap to buy a multi-button mouse and too lazy to look up the chording key or that they can use two fingers on the track pad.

* Using contextual menus does not prevent user configuration.

Yes it does, at least as currently implemented on Windows and in many custom interfaces for programs. You either can use a custom menu or you can use the one supplied by the developer, but usually you cannot merge the two into one menu and often there is no way to add the functionality from the custom menu into a standard menu. This is an extremely common problem for people trying to use an alternative input device, like people with palsy.

Argumentum ad hominem, too. Not guilty. I use OS X regularly, I've used Macs for almost a quarter of a century. OS X is my primary desktop.

This is not an ad hominem attack, nor was it a description of you. This was describing the characteristics that lead people to repeat this misperception in the media. So tell me, are you one of the people who is too lazy to learn or too cheap to buy a new mouse?

Menus are far away (1)

tepples (727027) | more than 5 years ago | (#23749673)

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.

Re:Menus are far away (1)

99BottlesOfBeerInMyF (813746) | more than 5 years ago | (#23750615)

* 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 button either. 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. If it is in the regular menu or the regular menu and the right-click menu you're okay. The same goes for styluses, touch screen kiosks, voice activated interfaces, etc.

It would be nice to think developers would always include a function in a place other than the right-click context menu as well, but that simply doesn't happen as may years of experience has shown. Having a one-button default is the only method that has succeeded.

Re:Menus are far away (0)

Anonymous Coward | more than 5 years ago | (#23750847)

Fitz law says that the Apple menu bar is easier to reach than a Windows menu bar, even if the Windows menu bar is nearer.

The reason is because the Apple menu bar is flush with the top of the display, so it is effectively infinitely tall. You can slam the mouse over there at high speed with little need for precision.

A Windows menu bar, on the other hand, is only a few pixels tall. You can accelerate the mouse towards it, but you need to slow down and stop carefully on it, in case you go past it.

Re:Took them long enough (1)

argent (18001) | more than 5 years ago | (#23750427)

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 century, rarely even had any user interface experts provide an example of a study other than Apple's original flawed work.

I can also use argumentum ad verecundiam if you want. I have 20 years of experience as a system administrator, supporting users that ranged from clueless executives and secretaries to programmers with PhDs. The biggestTrue, they are not easily discoverable, but that is only one part of usability. Novice users don't need to discover them. Advanced suers have no problem figuring them out quite quickly.

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.

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

If you mean iTunes, that's a custom UI developed on the Mac and ported to Windows that Apple has used as a testbed for user interface ideas. If any application should have evolved into a witness for the best that Apple could do, that's the one.

[contextual menus preventing customization] Yes it does, at least as currently implemented on Windows

I'm not a Windows user, and I'm not comparing OS X with Windows. I'm right now using contextual menus WITH user customization on OS X. I have done the same on other window systems... all the way back to the beginning, back before the Mac wis a twinkle in Raskin's eye.

Re:Took them long enough (1)

99BottlesOfBeerInMyF (813746) | more than 5 years ago | (#23750857)

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.

Hold your horses there partner! We're talking about chording keys that substitute for extra mouse buttons, not any other UI features. Stay on topic. Are you still looking for the ctrl key to use with your muse button or trackpad? Are you still trying to figure out that if you have two fingers on the trackpad when you click it works like the second button on other systems?

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
If you mean iTunes, that's a custom UI developed on the Mac and ported to Windows that Apple has used as a testbed for user interface ideas.

I don't know of any functions in iTunes that I have to use a second mouse button for. I'm not seeing you support your assertion with any examples. If the problem is real, surely you can think of some application where you need the second mouse button on OS X.

I'm not a Windows user, and I'm not comparing OS X with Windows. I'm right now using contextual menus WITH user customization on OS X.

So what is your problem with Apple's implementation of the second mouse button? You claim to be using it, so how have they hindered that use case? They support features by default if you have a second button and it is possible to customize them, unlike other popular implementations where you are forced to use them and they cannot be customized. I'd say Apple is ahead of the curve here.

Re:Took them long enough (1)

init100 (915886) | more than 5 years ago | (#23747075)

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:Took them long enough (1)

prockcore (543967) | more than 5 years ago | (#23750495)

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:Took them long enough (2, Informative)

Ephemeriis (315124) | more than 5 years ago | (#23746141)

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:Took them long enough (1)

init100 (915886) | more than 5 years ago | (#23747105)

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:Took them long enough (1)

kscguru (551278) | more than 5 years ago | (#23749539)

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 applied in source - which might be good enough for the few thousand people who always run the bleeding edge kernel, but has to trickle through a kernel release cycle (~3 months) or even wait for a distro upgrade cycle to pick up a newer kernel (~6 months for Ubuntu / Fedora, ~2 years for RHEL, maybe 4 years for Debian-stable?). No shortcuts, this isn't a backportable security fix.
For an average Ubuntu user (just picking a popular Linux distro here, no flamewars) and an average Mac OS X user, the 10.5.3 update came out a LOT sooner than the next Ubuntu 8.10 update. Sure the five people who actually care about this have the option of recompiling on Linux, but for everyone else, the closed-source product cycles are moving a lot faster. There's a world of difference between fixing in source and fixing on my local machine, a world open-source zealots conveniently omit when mouthing off about how fast open source can fix things. (Hint: I'll bet Apple fixed DTrace in source in a week also.)

Linux is quite good about cycling security fixes through very fast. Anything else - new features or non-security/stability fixes - tends to take many months or even years to percolate to the world at large. Which puts Linux-based OSes (e.g. distros) squarely between Apple (updates every few months) and Microsoft (SPx every few years) for slow product cycles. Note that this isn't the fault of Linux kernel people - it's the whole distro model, which should be a sign that an OS - even an open source OS - is a complicated beast that necessarily has long release cycles.

Pirst Frost! (-1, Redundant)

Anonymous Coward | more than 5 years ago | (#23745591)

Finally..

LOL! (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#23745811)

Fail!

22 January - 11 June (-1, Flamebait)

Daimanta (1140543) | more than 5 years ago | (#23745635)

About 5 months! Damn, even Windows fixes its bugs faster. That's just sad and just another reason not to use Apple software.

Re:22 January - 11 June (1, Insightful)

Anonymous Coward | more than 5 years ago | (#23745729)

Are you really going to sit there and tell me that there are no bugs in Windows (or Linux) more than five months old? Don't be ridiculous.

Re:22 January - 11 June (1, Insightful)

Anonymous Coward | more than 5 years ago | (#23747263)

Isn't Windows one big bug? :P

Re:22 January - 11 June (1)

somersault (912633) | more than 5 years ago | (#23746609)

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.

Good news (3, Interesting)

Anonymous Coward | more than 5 years ago | (#23745679)

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:Good news (1)

Constantine XVI (880691) | more than 5 years ago | (#23745781)

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 (5, Funny)

Anonymous Coward | more than 5 years ago | (#23745883)

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

Boot times... (1)

argent (18001) | more than 5 years ago | (#23746419)

I'm sick of boot times measured in minutes.

What is this, 1980?

Re:Boot times... (1)

rekoil (168689) | more than 5 years ago | (#23747157)

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

CD vs Floppy (1)

argent (18001) | more than 5 years ago | (#23747515)

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:CD vs Floppy (1)

laffer1 (701823) | more than 5 years ago | (#23749929)

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

Re:CD vs Floppy (1)

argent (18001) | more than 5 years ago | (#23750577)

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:CD vs Floppy (1)

swimmar132 (302744) | more than 5 years ago | (#23750255)

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:CD vs Floppy (1)

argent (18001) | more than 5 years ago | (#23750503)

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.

Re:Boot times... (0)

Anonymous Coward | more than 5 years ago | (#23747193)

I'm sick of boot times measured in minutes.

What is this, 1980?
Well, we could always measure it in microseconds and give it in standard form to 3sf, if you'd like. We'll even throw in SI compliance, free!

Good going apple! (4, Funny)

YeeHaW_Jelte (451855) | more than 5 years ago | (#23745703)

Your evilness index has just dropped from 45.8 to 45.3

Keep up the good work!

Re:Good going apple! (0)

Anonymous Coward | more than 5 years ago | (#23745865)

Come on, everyone knows that they got karma to burn that's why they took their precious time to deliver.

Apple fixes overstated bug... (1, Interesting)

Anonymous Coward | more than 5 years ago | (#23745875)

...and slashdot bends over backwards to apologise for ever doubting them.

You'd never see that happening if the same thing applied to Microsoft.

Re:Apple fixes overstated bug... (0)

Anonymous Coward | more than 5 years ago | (#23746321)

You'd never see that happening if the same thing applied to Microsoft.

Maybe. Can you provide an example of Microsoft independently deciding to be less evil? Hard to know until it's actually happened.

Re:Apple fixes overstated bug... (1)

bytesex (112972) | more than 5 years ago | (#23746733)

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

Quietly, quietly (4, Insightful)

gonerill (139660) | more than 5 years ago | (#23745929)

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 (1)

hostyle (773991) | more than 5 years ago | (#23746097)

Quietly, as in with a minimum of fanfare or huge public announcements ala "Announcing Leopard with better spots (comes with paint remover for the ones we painted ion before)".

You know the way MS markets things: Windows XP SP3 - "Like omg its the bestest SP we've ever released! Now with 10% less bugs! PS. we recycle chairs - XP is now more green. Save the trees, send your old chairs to Steve."

Re:Quietly, quietly (1)

x_MeRLiN_x (935994) | more than 5 years ago | (#23746697)

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.

Re:Quietly, quietly (5, Insightful)

stewbacca (1033764) | more than 5 years ago | (#23746211)

"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 (3, Informative)

timeOday (582209) | more than 5 years ago | (#23747095)

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:Quietly, quietly (1)

Wooky_linuxer (685371) | more than 5 years ago | (#23746243)

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.

Give me a break. (0, Flamebait)

ipjohnson (580042) | more than 5 years ago | (#23746813)

How many people here where actually affected by the D-Trace bug in OS X. I'd be willing to lay down 100 bucks that say 90% of the people that complained had no idea the bug was there until the story was posted ... including you. So why get so high and mighty about something doesn't even change your day to day activities. Seriously I own a Mac and I write software on it from time to time but does some missing functionality in D-Trace make a difference NO!

Its just another reason for D-Bags like you to make a stink.

Re:Quietly, quietly (1)

cgreentx (990146) | more than 5 years ago | (#23747309)

Quietly as in Apple rarely even gives the bugs/issues they fix a single line in the release notes, much less a KB Article explaining the bug. In supporting OSX I've recently spend months fighting AD Authentication issues only to have the issue suddenly fixed in 10.5.3 with no acknowledgment from Apple there was ever even a problem.

Mac's Suck (-1, Offtopic)

imus (1229508) | more than 5 years ago | (#23746123)

I can prove it. Try this yourself. 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. You can even compile a GNU GCC suite from xCode, but there is no way to get around the fucked-up ld. How stupid is that?

Re:Mac's Suck (2, Insightful)

antifoidulus (807088) | more than 5 years ago | (#23746283)

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 (1, Informative)

Anonymous Coward | more than 5 years ago | (#23746895)

There are better free software programs out there for writing c++ code
Really? What? The only open source IDEs I've found that come close to being as powerful as Xcode are KDevelop and Eclipse. KDevelop is a bit buggy, its autocompletion is slow an inaccurate, and, obviously, you have to be using KDE and X; Eclipse is a massive memory hog, slow, and looks ugly as sin on OS X.

not to mention you could always just call good ol' gcc on the command line...
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.

Re:Mac's Suck (3, Insightful)

mwlewis (794711) | more than 5 years ago | (#23747981)

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:Mac's Suck (1)

keytoe (91531) | more than 5 years ago | (#23749533)

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

Re:Mac's Suck (1)

mwlewis (794711) | more than 5 years ago | (#23749847)

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:Mac's Suck (0)

Anonymous Coward | more than 5 years ago | (#23748217)

Manually calling gcc is simply impossible, unless I want to waste half a day every time I need to compile something.
Are you being deliberately argumentative, or does typing "make" really take you half a day?

Re:Mac's Suck (5, Informative)

Plantain (1207762) | more than 5 years ago | (#23746297)

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:Mac's Suck (1)

mzs (595629) | more than 5 years ago | (#23749195)

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:Mac's Suck (1)

dadragon (177695) | more than 5 years ago | (#23749399)

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:Mac's Suck (5, Informative)

Halo1 (136547) | more than 5 years ago | (#23746409)

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:Mac's Suck (0, Troll)

imus (1229508) | more than 5 years ago | (#23746715)

I still contend that ld is fucked-up... they have changed it.

Re:Mac's Suck (1)

vijayiyer (728590) | more than 5 years ago | (#23746889)

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:Mac's Suck (0)

Anonymous Coward | more than 5 years ago | (#23747969)

I can prove it.
You can't even spell "Macs suck," much less prove it.

Try this yourself. Write a simple c or c++ hello_word program. Then try to compile and link it with Xcode using -static.
Why? No, really - why? The limitation you refer to only applies to executables, not to libraries. If you want functions that are in your executables to be dynamic and shared with other apps, just move them into a dynamic library of their own.

It won't work b/c Apple has fucked-up ld. You can even compile a GNU GCC suite from xCode, but there is no way to get around the fucked-up ld. How stupid is that?
How stupid is it to use dlopen() on an executable, instead of factoring its shared functions into a separate dynamic library?

DTrace 2.0: Now 30% Less Crippled! (2, Interesting)

NoCowardsHere (1278858) | more than 5 years ago | (#23747325)

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 profile _anybody's_ code, in order for example to diagnose performance problems on your computer perhaps caused by those programs. Apple has intentionally left that feature out. So it's arguably still pretty crippled.

They haven't "fixed" it at all (1)

gleffler (540281) | more than 5 years ago | (#23747391)

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:They haven't "fixed" it at all (1)

ahl_at_sun (853337) | more than 5 years ago | (#23748125)

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.
Yeah not so much. I hate to be put in the position of defending DRM, but Apple clearly had some external motivation for limiting access. 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. Further they've created a protection scheme that is as pro forma as you could imagine.

Good news doesn't sell (2, Insightful)

snowwrestler (896305) | more than 5 years ago | (#23748007)

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

ptrace() (0)

Anonymous Coward | more than 5 years ago | (#23748441)

Any idea when they'll fully implement ptrace() or is that not on the table?

Apple Quietly Fixes DTrace but (0, Flamebait)

pandrijeczko (588093) | more than 5 years ago | (#23748831)

...for those fanbois who still feel the need to personally thank Uncle Steve, he is currently bent over in reception with his trousers round his ankles waiting for you.

Not much of a hurdle? (1)

eudaemon (320983) | more than 5 years ago | (#23749293)

So just as a tought experiment, what's to keep me from compiling code that sets this flag and then
using oh I dunno any hex dump program to see what the system call and parameters looks like?

Once I know that pattern I can easily patch any binary in the system with perl and remove the offending
system call by instead setting the syscall parameter to a safe value, substituting in NOPs, etc.

I guess what Apple is saying is they don't want casual dtracing of their binaries because anyone
savvy enough can remove the system call, as of course they still have root.

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

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...