That link says you CAN run linux on xbox 360, at least on models with older firmware. Seriously, this is supposed to be the example of Impossible To Hack?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Discussion Over Apple's Modification Of Sun's DTrace
- Thread starter MacRumors
- Start date
- Sort by reaction score
That link says you CAN run linux on xbox 360, at least on models with older firmware. Seriously, this is supposed to be the example of Impossible To Hack?
It's somewhat disingenuous to compare a box deployed as a sealed system (essentially a hardware solution even with magnetic media inside) with a multipurpose platform's OS designed to allow the user to load his or her own software with privileged access.
This is something that's not going to change with Mac OS X - Apple can not "seal" it so that users can't load their own programs with root access, too many ISVs depend upon this.
This statement couldn't be more wrong. DTrace is a good thing for all users and developers. For users, you're empowered to understand the applications you use every day. For developers, you've empowered your users to collaborate with you to improve your program. We've seen countless examples of exactly this interaction for Solaris from the day in 2003 when we first made DTrace available to users. We were finally able to diagnose problems in situ rather than trying to replicate them back in our labs. And customers are able to gather their own data which is invaluable in understanding and fixing their problems.
Well, that's not really the point here. You see, they claim that they proudly port a good (and GPL) inspection tool that truly help in debugging softwares when in fact, they broke it (or adapt it to fit their needs). Now, to take any tool (GLP or not) and adapt it is not the real problem but render it partially useless (by changing bits and that to fit their needs), that's a different business from my point of view...
Anyway, the problem is not about iTunes or DMR or DTrace itself but it's more about making a tool available which, in it's present form, can't do its job properly.
It's a little bit like saying: Now with OS X, whenever an application crash, you can just look at the logs and see what happened and by looking at the log you can only see "Error -64" or even worst, you can't see any error being reported at all!
No big deal (for non-developers) but no medal awarded either...
The bad thing about dtrace is that it can't be run as a non-root user. Or is it possible?
PS: I also asked this question over at discussions.apple.com, but got no fulfilling answer yet.
PS: I also asked this question over at discussions.apple.com, but got no fulfilling answer yet.
I don't supposed you are running iTunes in Solaris, so I assume you were looking for file lock contention or issues between two applications that talk to each other over shared memory. Unless it is a single application or a set of applications that work together to solve a problem, or that share specific resources like a block of memory, a lock, or a file, I do not see why one would care what another application is doing. The os is a multitasking multi user system, most programs run as separate processes and have little to no interaction with each other other than compete for cpu, disk space and virtual memory space. So I dont see why most people would care.
Most people have no need to know what iTunes is doing or how efficiently it does its job.
Most user are that .... USERS. They could care less how something works as long as they can get their job done.
While it is useful to have the user do things for you while reconstructing an issue that QA missed, most users are not technical enough to be helpful. If you are dealing with programmers and system admins, they can be very useful, but they are the minority of the USER community, unless your application is for one of those the average user can do little to help. Better to remote connect and do it your self with the user on the phone.
I like to see a show of hands of how many non-developers in this forum have used Dtrace with an Apple developer to solve an application or OS issue.
Fair enough. Now everyone do this in the Terminal application:
sudo dtrace -c date -n 'pid$target:::entry{ @[probefunc] = count(); }'
Congratulations, you've now all used DTrace. If this had been a real bug, you would have been able to gather information for a developer working on your problem.
Now: a show of hands of how many non-developers in this forum who have hit a bug in some application and been unable to get a developer of that application to help solve the problem.
Actually, I'm not a developer, I'm a Systems Admin and Analyst. (For only 20 years or so.) While we've been focusing on iTunes, it's actually the modification of an important diagnostic tool that has me concerned - other apps can be set the same way, and that just adds to the issue.
I used to be a senior engineer at Sun, and the introduction of DTrace was a real thrill for me. I'm used to working on a system from a holistic approach, and missing parts of the picture make it difficult to do what I do best.
Let me clarify, I never said it was not useful to a developer to have someone technical run commands like dtrace when the developer receives a call about a possible bug.
I said that most users would have no clue what to do and no clue as to the meaning of the output, also most software development companies with the exception of very small ones allow a customer to talk to their development / support staff directly. Most times you have to write to them and hope the developer calls you back. So it would be unlikely that a user would know how to use dtrace and is unlikely a user would know which application to look at and which data being displayed is significant, as such the email to the company will have little of value as the user did not run dtrace or the debuger to look at the registers. Which means that until the developer calls back and ask for specific things the user is completely clueless other than the symptoms he/she sees. Not only that, but the user may not even be able to use sudo or become root to run some of these commands, the user maybe a regular user at a corporation with few rights if any.
The average Grama and secretary does not know how to use dtrace, how to spell it, what it means, and what is significant from its output. Not every user is a sysadmin or a programmer, as a matter of fact few are unless you make software targeted at them.
The reason for this is the level of access to raw data that you get with DTrace. For example you can see all data that is being read/written to disk or the network. You could, if you wanted, re-implement something like tcpdump with DTrace. If non-privileged users were allowed this access then that would break the entire security model of OS X, any user could see what any other user was doing and intercept their data. As noted in the discussions article you've linked it appears to be possible to give users the rights to run d scripts without having to give them whole root access if that is what is desired.
For example there's a Brendan Gregg d script called 'shellsnoop' here that will display keystokes and command outputs from a users shell. (btw I've no idea if this would work without modification on OS X it's designed for Solaris, but the concepts are the same).
Edit: In further response to your question on apple discussions
DTrace works perfectly well against applications running as unprivileged users, it's just the DTrace script itself that must run as root.
BTW your crashing problem is almost certainly down to a permissions issue.
Oh, no doubt and I don't think we're actually in disagreement. I'm really not trying to nitpick a certain case or users, but rather express my distress at the concept that it's kosher to modify a diagnostic tool of this nature.
I'm not calling Apple evil, and I'm not going to toss my MacBook in the trash. Having worked for software, hardware, and just about every other industry, I can say that all companies do questionable things from time to time. But, if we don't air our dissatisfaction, then the people involved, then we're not being honest with ourselves. Even if Apple ignores me, it's worth it to say, "This is wrong."
All those who have no clue what this thread is about please raise your hand and say, Aye. Good. Now I don't feel so stupid.
I do think I learned a little something though, which is a nice thing about this forum. There are some very bright people here.
almost one 100% with you on this, just one nick pick...... The place to complain about apple stupid practices is the support section of their site.
This is a good place to state the problem one sees, explain it why it is a problem and ask everyone to go complain at the Apple support site. Sort of rally the troops. Unless enough people complain rarely things change.
Umm yeah...
Back peddling I see?
---
As long as the users have access to the hardware that decrypts the DRM media and plays it, it can be broken.
Even without physical access to the hardware they still have other means to record said media to something else. Like those bootleggers with video cameras at movie theaters.
Back peddling I see?
---
As long as the users have access to the hardware that decrypts the DRM media and plays it, it can be broken.
Even without physical access to the hardware they still have other means to record said media to something else. Like those bootleggers with video cameras at movie theaters.
Let's put it another way.
If SUN Microsystems owned iTunes you would see a dtrace that had this and more disabled.
If SUN Microsystems owned iTunes you would see a dtrace that had this and more disabled.
I would agree with you if Apple didn't delete posts like they are the thought police out of 1984...
The difference between hardware and software is that, given enough time, a hobbyist hacker can debug enough code to recover a key or reverse-engineer a protection scheme, because all the tools that one needs are right there in front of you.
Imagine trying to reverse engineer a TPM chip. It's probably printed at 90nm resolution onto a silicon substrate, and then sealed in plastic. Much harder to study and thus much harder to reverse engineer.
To the extent that content owners can force these closed-source hardware solutions on customers, they will be able to dominate content in a brand new way.
I'll have to take your word for it regarding Solaris users. But you are seriously mistaken if you think asking OS X users to kick off DTrace sessions is part of an effective support strategy.
I do need to come clean on this though: There's no reason for a developer to try to take advantage of this by setting the LNOATTACH flag; it won't protect your app from hackers and will only annoy system administrators (apparently there are a very large number of them).
You still can hack the hardware though and even more simply you bypass it. As long as you have access to the hardware you can do that and consumers aren't going to be too keen on having hardware they can't access at all.
It's just like if/when they make HDMI use DRM/protection schemes to ensure you're connected to "proper equipment", you get a box to bypass that which will say "I'm a good piece of equipment"... Simple enough...
DRM schemes would work better with software vs media because software provides complex functions (but still can be hacked) where as media is viewable to the end user otherwise it's worthless... You have the analog hole which just simply is not going to be plugged unless something radical happens and even then it's likely to have work around.
The main point being, it is not impossible to hack DRM, no matter how great it is, the same with encryption...
Here here. Apple is incredibly open source friendly. That they should choose to protect certain parts of their software (the bit that is attached to the iPod, their big cash cow) is entirely understandable, and reasonable.
When will people stop getting on their high horse over things like this and recognize the good that people do.
So they say. The problem is, it isn't true. I never have to break the DRM scheme to copy data to my own discs and start selling bootlegs that will play just like legitimate copies. I think that's why HD drives are still hard to get, they want to prevent copying in hardware but that has a substantial risk of detecting false positives without a software workaround if that happens. It also means you can't yet build HD media servers, not that the studios care how consumer-friendly their product is. The studios should have learned from software companies, who attempted to enforce use restrictions with dongles and other hardware in the 1980s and were eventually forced to abandon such schemes due to intense customer dissatisfaction.
I guess by "the analog hole", you mean displaying the image on a screen (or playing the sound through a speaker). You're right, given our current understanding of physics, it is impossible to share information with somebody without them being able to capture that information in some form. I don't think anybody disputes that.
But given that the media is digitally encoded and has an all digital path from decoder to display, I still don't think your viewpoint on "bypassing" hardware makes any sense. The "trusted" devices can recognize each other using public key encryption. Sure, the private key is present, but if it's hardcoded on a piece of silicon, how are you going to recover it?
Nothing is literally impossible, but recovering a 1024 bit private key with brute force would take more years than there are particles in the universe.
There is a fundamental difference between hardware and software, and its mostly economic. Basement hackers don't have access to the tools required to reverse engineer a computer chip. Sure you can see what signals go in and out, and you can attempt to bypass, but there are elementary encryptions systems that would make it impossible to "bypass" a chip unless you knew the private key.