Zones have a distinct maturity and robustness over LxC (to be expected), ZFS is the filesystem I wish we could have, dtrace isn't a bolt-on etc.
It would be nice to see it fully open-sourced again as I think the one thing it has working against it is a smaller community and it lacks the same size army of driver authors.
[1] http://www.youtube.com/watch?v=-zRN7XLCRhc
[2] http://www.youtube.com/watch?v=7YN6_eRIWWc
[4] https://github.com/joyent/illumos-joyent
Beyond the basic POSIX compatibility, there are lots of differences across UNIX systems, each has their plus and minus points.
Might? SystemTap's been stable & out of the box on RHEL 5 for years. The extensive list of default tap points are supported on production by RH. When I was doing systems stuff 5 years ago we used it for double checking TCP socket options that weren't normally exposed to userspace tools.
Dtrace can do some awesome stuff stap can't, like trace something from userspace down to kernel space. But systemtap does provide live instrumentation on running kernels and has for years.
PS: Just saw p93. Sun got in trouble for the obvious "Setting up SystemTap is difficult on distros that don't maintain, support, use or like SystemTap" years ago. This is repeated on p 93. Stop it, this makes Joyent look stupid, you're better than this.
And p100. Re: 'several million dollar E10K' performance? Red Hat were replacing them with Xeon's by 2003 (with Sun's old sales staff) and crushing them. Though that was SPARC's fault not Solaris's.
Red Hat can certainly say that SystemTap is obviously a priority on their OS, and they can only make best effort for others. I said this in the talk. Indeed, a working SystemTap should be an incentive to run RHEL. It is a compelling argument -- the benefits of a working SystemTap are enormous (which I also explained in the talk). Sun made basically the same argument for switching to Solaris: a working DTrace.
Although, I'm not sure that using SystemTap is entirely safe for production yet, which I said was the most important priority. I notice that this related kernel panic is still not fixed:
http://sourceware.org/bugzilla/show_bug.cgi?id=2725
Although some recent and promising progress has happened in the past few months, as noted by the bug! I only care about this bug because I sometimes trace large subsets of the kernel (eg, all functions in a module or driver), and I think I've hit the same related issue. I don't actually need to trace everything.
You said that DTrace can trace from userspace to kernel, which SystemTap can't. I'm not sure if there's a specific case you're referring to, but SystemTap nowadays can indeed trace userspace to kernel (via uprobes), and a lot of work has been happening to get SystemTap userspace tapsets to work.
As for setting up SystemTap being difficult on distros that don't support or maintain SystemTap. Well, almost all of my customers run Ubuntu. If they hit perf issues, do I convince them to switch to RHEL? (The approach that Sun made for DTrace.) Or is this a problem to be taking up with the other Linux distro maintainers? Which goes back to my original point: when will Linux get this? :-)
apt-get install systemtap linux-image-amd64-dbg
Are you accusing Brendan of misrepresenting SystemTap on slide 93? If so, could you be specific as to what that misrepresentation is? Brendan has a ton of experience earnestly using SystemTap (or rather, trying to use it), and it's hard to see how sharing that experience makes either Brendan or his employer "look stupid." For more details on Brendan's explorations of SystemTap:
http://dtrace.org/blogs/brendan/2011/10/15/using-systemtap/
1. 'might' implies the future. As you can tell from the post you're replying to, Systemtap is present thing. I think I actually put most of the tapsets shown on the Wikipedia page around 2009, and I was using them then.
2. Also, as the author partially acknowledges in the next slide, Ubuntu is the dumbest place to illustrate a typical Systemtap experience. I suspect that's deliberate, rather than ignorance as Sun tried that a few years back and I don't think anyone with any interest in the matter is ignorant enough not to remember the shitstorm.
As I've written elsewhere: if your customers mostly run Ubuntu, then test dtrace on Ubuntu too. It'd give you just as accurate impression about what the dtrace 'experience' is as installing SystemTap on Ubuntu.
Edit: actually looks like Joyent wrote the shitstorm post for a few years ago, you've still got it up, you still don't see anything wrong, and you just linked to it.
christ read the HN comments from 2011. https://news.ycombinator.com/item?id=3118416
Edit 2: you're Bryan Cantrill. You didn't seem to care much about performance a while ago: http://cryptnet.net/mirrors/texts/kissedagirl.html
Edit 3: more Cantrill classiness http://www.quora.com/Node-js/Why-did-Ben-Noordhuis-decide-to...
Sorry to anyone who thinks I've gotten personal, but this guy is a well known... unsavoury character.
How does it make joyent look stupid? Dtrace is miles ahead of Systemtap, especially when it comes to installation because dtrace is generally embraced where it's being used as a default installation which systemtap is not and I don't have to make a monkey dance if I upgrade the kernel.
On a system with dtrace like OS X tracing tools like dtruss are basically just wrappers around dtrace. It's very natural to the platform.
Possibly I missed the golden era of Sun field support, or perhaps it was more a regional thing, but I consistently get vastly superior support from Red Hat than I've ever had from Sun, even when running M-class Sun kit.
And let us not speak of Oracle.
I really wanted to get it working. One of my colleagues (who was from Sun) actually left and went to work for Joyent, presumably at least partly because of the frustration with the lack of a dtrace like tool.
The incompatable nature of the license was so linux could not merge things like ZFS and dtrace.
it was yet more Sun licensing games that only hurt adoption in the end, like their Java shenanagins.
Summing it up as "aww gee shucks licensing problems have struck again" ignores the fact that such crap was an intentional power-play from sun.
A clash of politics had a sad effect on actual technology.
If Linux has enough RAM, it will outperform Solaris, but, it is quicker to get bogged down if there is swapping.
(These observations are from about Centos 5.x , so, perhaps they are no longer valid, however.)
$ time perl -e 'for ($i = 0; $i < 100_000_000; $i++) { $s = "SCaLE12x" }'
real 0m33.59s
user 0m33.57s
sys 0m0.00sI'm only jealous because I'd really like my employer to buy a T5 for compiling and running our software on Solaris SPARC, but unfortunately I don't think it's justified given the state of the platform.
Also, I'm confused by the claim that Solaris doesn't have the vfsstat utility; yes, it doesn't have that utility, but it does have "fsstat" which provides VFS-level statistics. So it'd be helpful to see a more detailed comparison.
So if you really don't want your slides read, put them on slideshare.
Now there's one thing those guys can learn from Linux: modesty.