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? Right, that's why you see so much content available from record and movie companies available on Linux.
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. Totally. And there's absolutely no DRM on a DVD player and Blu-ray is making things even less restrictive.
But surely this was posted by a slashdot-focused eliza program -- no human is this naive.
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.
None of what you've said there is really accurate. The issue is not inefficiency; indeed, it is a design flaw in how they chose to implement the security restriction. And if you actually read the blog post:
To say that Apple has crippled DTrace on Mac OS X would be a bit alarmist, but they've certainly undermined its efficacy and, in doing do, unintentionally damaged some of its most basic functionality.
Actually, Leopard's DTrace is broken, and that was the point of the blog post. Here's the issue: DTrace programs that would normally work and collect valid data will fail if a process is running with Apple's trace-me-not bit set. Forget tracing iTunes or other applications that don't want to be traced. It's that probes that should fire don't as an unintended side-effect of Apple's hack to obscure certain applications.
A much smarter approach would have been for Apple to deny visibility into such a process, but still allow a user to monitor system-level events (e.g. timers and system calls). This would have allowed for the (questionably motivated, and highly circumventable) protection while not damaging DTrace and correctly phrased queries.
I wrote OProfile, and I currently use DTrace daily, and I can assure you that you are wrong when you claim they do the same thing.
OProfile is useful for measuring system-wide resource consumers (for example, you can see what pieces of code are causing cache misses in the kernel when your apache process is in the kernel etc, or which user processes take up the most CPU time).
DTrace can also do something similar (though it needs a little more work yet). But DTrace does a LOT more than this. Imagine a system-wide (kernel, binaries, libraries) 'strace', where you can trivially choose what to print out, and what parts to strace, and under what circumstances. DTrace does even more than that.
OProfile can't tell you exactly why your system call is returning EINVAL. OProfile can't tell you why your application is causing cross-calls. OProfile can't tell you what processes are writing to what files, in real time. OProfile can't debug race conditions.
OProfile is a profiler: it does its job and nothing more. DTrace is, essentially, an instrumentation suite; one of its abilities is to function as a simple profiler.
You won't really get a notion of why DTrace is so useful until you try it.
The key question is; if Sun tries to kill OpenSolaris development, can they do it?
Ignoring the question of why Sun would try to do that (some sort of exotic open source poison pill?), I suppose they could turn off the juice on OpenSolaris.org, but even that wouldn't shut down development. The code is in the open and it's under a license that explicitly allows people to use it and modify it. No one -- not even Sun -- could keep people from building their own distros, doing their own development, and building their own communities (all of which is happening today with Sun's encouragement).
How this blatant FUD could be confused with actual newsworthy content is a credit to IBM. The assertions put forth in the article seem to have only a casual relationship with reality. For example:
Sun could do "simple things" to build a real OpenSolaris community if it were serious about doing so, Frye said. "They would push their design discussions out into the forums, so people can see what's going on," he suggested.
Take a look at the discussions page at OpenSolaris.org and that's exactly what you'll see. Not only are there discussion forums for established components (ZFS, DTrace, Zones, etc.), but for projects which are still in their early stages (e.g. BrandZ, Xen, clearview) that are encouraging community involvement for testing and development.
Components of OpenSolaris are also showing up in other operating systems: DTrace will be in the next release of Mac OS X and FreeBSD. Speaking personally as one of the DTrace engineers at Sun, it's been quite a pleasure working with both the Apple and FreeBSD kernel engineers -- pretty decent community for a "facade".
DTrace isn't just for kernel developers and sysadmins -- it's also for any type of developer. Take for example the recent DTrace support for Java, php, and Ruby. To your second point, you care about DTrace because you care about absolute performance. Maybe yours is a configuration that never suffers from performance degradation during a period of aberrant activity, but most applications do have some conditions where performance drops unacceptably. In those cases, you're at a huge disadvantage on a system that doesn't have DTrace to help you diagnose and resolve the problem.
explained in a way that probably only makes sense to hardware/assembly geeks. (i.e. Not me)
Here's a higher level explanation: everything's fine.
Here's a slightly lower level explanation: you basically can't be too paranoid when you're writing code that can never fail. One form of paranoia is to express what you think are the certitudes of the system so that it will fail immediately if those constraints are violated. This is an instance where an assertion was added to address a previous violation.
This article has all the sophistication of a 5-year old looking up 'anus' in the OED. Someone already pointed out the confusion between the processor clock and the system clock -- a confusion that would have been avoided if the author had read the code or even the rest of the comments.
More ludicrous is the author's supposed identification of a Mark Felt lurking in the shadows of the DTrace code:
The much-vaunted dynamic tracing (dtrace) feature of Sun's system may not be as safe to use as most people think.
That's based on what? The two ASSERTs that follow the cited comment? This one doesn't go all the way to the top...
BN: Is Community Source phased in throughout every product group, or is it targeted more towards improving core IBM software technologies that are more modular in nature?
... and the answer was, um, vague. IBM could make this believable by putting WebSphere or DB2 under community source.
Apparently the kernel and some core OS pieces have been released as OPEN while some 'binary stuff' is still closed.
Everything that could be released was. The pieces that were excluded were things to which Sun doesn't own the rights (e.g. certain 3rd party drivers).
Does anyone care to share if the free stuff alone is enough to have a bootable and runnable system? Do we have libc, init,/bin/*/kernel/* etc?
There's enough there (depending on your device situation), and it's been done, but it's kind of a pain. It's much easier to install Solaris 10 or Solaris Express and then slap down your own bits on top of that. Everything you mention is there:
libc - usr/src/lib/libc
init - usr/src/cmd/init /bin/* - usr/src/cmd /kernel/* - usr/src/uts
Yes! That was true, but not as of Solaris 10. The reason core files needed to be on the same machine that produced them was because they didn't include all the necessary information. In particular, they didn't include read-only data. Their genesis was around debugging on a given machine and in that case, dumping the read-only sections is kind of pointless. This was a frustration that affected every application developer who cared about post-mortem analysis; we in Solaris really care about debugging from first failure.
In Solaris 10, I did some work to make the content of core files adjustable and added text (aka code) to the default. Now when you get a core file, you can debug it on any other system regardless of the patch level, libraries installed or the version of your application that was running. Using coreadm(1M) you can adjust the content to, say, add the symbol table to the core dump or omit the gigantic ISM segment that you don't care about for.
So, yes, mdb(1) had some limitations in the past -- we've tried to address them in Solaris 10. If you have other issues preventing you from using mdb(1), post a comment on the OpenSolaris site.
I thought I was going to have to find a shill to ask that question... "Sir, we've never met before, have we?"
That answer depends on who you are. If you're a system administrator Predictive Self-Healing is going to raise the reliability of your systems and make management scads easier; SMF makes configuring the system a snap and lets you identify problems quickly and easily; Zones lets you partition the system without the management overhead of a bazillion OS instances; DTrace lets you understand everything that's happening on your system -- and who's responsible for the latest crap-up; Solaris Process Rights improve security and administrative overhead by splitting up the traditional binary notion of the super user. If you're a developer, you'll love DTrace -- I can't imagine developing with out it; the p-tools, truss(1) and mdb(1) are also great. If you're an end-user, well, Solaris's gnome sucks as much as anyone's gnome -- go use Mac OS.
DTrace has been lauded as one of the most innovative contributions to operating systems in 20 years. It's something completely from scratch and something people have been eager to understand how it works under the hood.
A lot of people draw analogies to their favorite tools (gdb, dbx, oprofile, ltt, dprobes, truss, ptrace), but it can really do more than all of those things put together. The largest differentiator is that it's designed for systemic analysis -- not just poking around an application or the kernel -- and these are exactly the types of problems which have resisted conventional analysis tools and have costed the most time and money.
A port or clone on another OS is certainly desirable and probably attainable. The code can't be integrated into the linux because that would violate the GPL, but I imagine it could be integrated into BSD.
Slashdot Mirror
Actually, Leopard's DTrace is broken, and that was the point of the blog post. Here's the issue: DTrace programs that would normally work and collect valid data will fail if a process is running with Apple's trace-me-not bit set. Forget tracing iTunes or other applications that don't want to be traced. It's that probes that should fire don't as an unintended side-effect of Apple's hack to obscure certain applications.
A much smarter approach would have been for Apple to deny visibility into such a process, but still allow a user to monitor system-level events (e.g. timers and system calls). This would have allowed for the (questionably motivated, and highly circumventable) protection while not damaging DTrace and correctly phrased queries.
http://slashdot.org/comments.pl?sid=113922&cid=96
Components of OpenSolaris are also showing up in other operating systems: DTrace will be in the next release of Mac OS X and FreeBSD. Speaking personally as one of the DTrace engineers at Sun, it's been quite a pleasure working with both the Apple and FreeBSD kernel engineers -- pretty decent community for a "facade".
FWIW, ZFS has N+2 redundancy: http://blogs.sun.com/roller/page/ahl?entry=double_ parity_raid_z
DTrace isn't just for kernel developers and sysadmins -- it's also for any type of developer. Take for example the recent DTrace support for Java, php, and Ruby. To your second point, you care about DTrace because you care about absolute performance. Maybe yours is a configuration that never suffers from performance degradation during a period of aberrant activity, but most applications do have some conditions where performance drops unacceptably. In those cases, you're at a huge disadvantage on a system that doesn't have DTrace to help you diagnose and resolve the problem.
That's not a Solaris developer (though I am) -- it's a customer who's been using DTrace for quite a while. He actually knows what he's talking about.
Prediction: transparency is to the the the 21st century as opacity was to the 20th century.
Here's a slightly lower level explanation: you basically can't be too paranoid when you're writing code that can never fail. One form of paranoia is to express what you think are the certitudes of the system so that it will fail immediately if those constraints are violated. This is an instance where an assertion was added to address a previous violation.
More ludicrous is the author's supposed identification of a Mark Felt lurking in the shadows of the DTrace code: That's based on what? The two ASSERTs that follow the cited comment? This one doesn't go all the way to the top...
Apparently the kernel and some core OS pieces have been released as OPEN while some 'binary stuff' is still closed.
/bin/* /kernel/* etc?
/bin/* - usr/src/cmd
/kernel/* - usr/src/uts
Everything that could be released was. The pieces that were excluded were things to which Sun doesn't own the rights (e.g. certain 3rd party drivers).
Does anyone care to share if the free stuff alone is enough to have a bootable and runnable system? Do we have libc, init,
There's enough there (depending on your device situation), and it's been done, but it's kind of a pain. It's much easier to install Solaris 10 or Solaris Express and then slap down your own bits on top of that. Everything you mention is there:
libc - usr/src/lib/libc
init - usr/src/cmd/init
Yes! That was true, but not as of Solaris 10. The reason core files needed to be on the same machine that produced them was because they didn't include all the necessary information. In particular, they didn't include read-only data. Their genesis was around debugging on a given machine and in that case, dumping the read-only sections is kind of pointless. This was a frustration that affected every application developer who cared about post-mortem analysis; we in Solaris really care about debugging from first failure.
In Solaris 10, I did some work to make the content of core files adjustable and added text (aka code) to the default. Now when you get a core file, you can debug it on any other system regardless of the patch level, libraries installed or the version of your application that was running. Using coreadm(1M) you can adjust the content to, say, add the symbol table to the core dump or omit the gigantic ISM segment that you don't care about for.
So, yes, mdb(1) had some limitations in the past -- we've tried to address them in Solaris 10. If you have other issues preventing you from using mdb(1), post a comment on the OpenSolaris site.
I thought I was going to have to find a shill to ask that question... "Sir, we've never met before, have we?"
That answer depends on who you are. If you're a system administrator Predictive Self-Healing is going to raise the reliability of your systems and make management scads easier; SMF makes configuring the system a snap and lets you identify problems quickly and easily; Zones lets you partition the system without the management overhead of a bazillion OS instances; DTrace lets you understand everything that's happening on your system -- and who's responsible for the latest crap-up; Solaris Process Rights improve security and administrative overhead by splitting up the traditional binary notion of the super user. If you're a developer, you'll love DTrace -- I can't imagine developing with out it; the p-tools, truss(1) and mdb(1) are also great. If you're an end-user, well, Solaris's gnome sucks as much as anyone's gnome -- go use Mac OS.
A lot of people draw analogies to their favorite tools (gdb, dbx, oprofile, ltt, dprobes, truss, ptrace), but it can really do more than all of those things put together. The largest differentiator is that it's designed for systemic analysis -- not just poking around an application or the kernel -- and these are exactly the types of problems which have resisted conventional analysis tools and have costed the most time and money.
A port or clone on another OS is certainly desirable and probably attainable. The code can't be integrated into the linux because that would violate the GPL, but I imagine it could be integrated into BSD.