David Boyes wrote:
On 3/26/09 2:13 PM, "Jeff Savit" <[email protected]> wrote:
> I'm going to avoid partisan issues, or at least attempt to do so :-) but
> some corrections on Sun-specific stuff:
> The first part of that is correct, but not some of the other parts,
> including the bit about OpenSolaris on SPARC.
The head of Solaris development disagrees with you. The previous comment was
a direct quote of his words.
Yet nonetheless, OpenSolaris on SPARC is coming.
> Solaris runs on millions of Intel
> systems now, and that's been an area of focus and investment (and should
> NOT be interpreted as disinvestment in SPARC).
Smoke screen. No one said you weren't investing in SPARC. I said that there
were internal reasons that were slowing up OpenSolaris on SPARC.
That comment wasn't directed at you, but every time somebody from Sun
talks about what we're doing on Intel, somebody pipes up afterwards and
says "oh, they are disinvesting in SPARC". So, I wanted to stave that
off. I'm aware of the issues related to OpenSolaris on SPARC, but didn't
feel the need to enumerate all of them.
=20
> In fact, OpenSolaris for SPARC is certainly coming. You can see a bit of
> discussion of that at:
> http://www.opensolaris.org/jive/thread.jspa?threadID=3D78357&tstart=3D=
<http://www.opensolaris.org/jive/thread.jspa?threadID=3D78357&tstart=3D=>
0
See above. There are a fair number of missing pieces still. Surprise--
they're some of the same missing pieces in the Z port. I wonder why. 8-)
Time. Budget. Resources. Priorities. Several of which I just stated.
>> They have been trying rather diligently to clean up the mess around thes=
e
>> issues, but basically the incentive to do the clean up necessary to make
>> this open-source-clean is not something they are prioritizing if they're
>> struggling to survive. I can't really argue with that, much as I would l=
ike
>> them to get on with it so I can do more to help them.
> Sun is indeed working diligently on this, and this is a priority, but
> not necessarily in areas that are important to David. Part of the reason
> for introducing new software in OpenSolaris, such as the replacement of
> the existing Solaris patch, package, and boot environment is to move to
> unencumbered replacements, as well as the reasons cited above.
All nice sounding, but that's not what your execs are saying to me. I can't
give your official position (that's why you have the sun.com address), but I
can tell it how I see it.
As is your right, and as is ours to set priorities based on our business
needs.
> DTrace is indeed cool, but the rest is simply wrong. DTrace and ZFS have
> been open-source since Day 1. ZFS exists on BSD and Mac OS X, and of
> course the issue with Linux is the incompatible license terms not the
> lack of source code. DTrace also runs on FreeBSD and Mac OS X.
Depends on if you consider CDDL to be open source. I don't find it
particularly open.
I understand that this is a point of controversy. Some will agree with
you, some will not.
I consider CDDL to be open source (as with the Mozilla Public License on
which it was based) and so does the OSI. But I recognise that not
everyone will share that stance.
It's what made your port to z feasible.
>> As cool as it is, dtrace syntax is fugly.
> No it ain't. :-) Oh, well, that's in the category of "degustibus non est
> disputandem". I find it a natural expression of the "too cool to be
> without" functionality, and in any case there's many pre-cooked scripts
> out there, and a GUI tool too. Like any other language it requires some
> study and application of effort, and until then it may look odd to the
> casual observer.
Any language where syntactic white space is significant is IMHO fugly. Same
reason I think Python is fugly. And S. And Matlab/Macsyma for that matter.
Useful as all hell, but still fugly. No challenge that there are lots of
nifty examples, but that doesn't fix the basic syntactical complexity
ickyness.
Please remind me which part you have in mind. From the DTrace guide,
document 819-3620, page 71 "Whitespace can be used to separate any D
program elements and to indent action statements."
And no Java byte code as a prerequisite, either :-)
Religious argument. We're allowed to disagree on the fugliness of Dtrace.
It is what it is. It didn't have to be what it is.
> I suggest you have a
> closer look at IPS before you dismiss it out of hand, too. It's not just
> the packaging, it's also the ability to build a boot environment based
> on a snapshot that can be rolled back, and only consumes disk space
> relative to the previous version. Very nice, IMO.
To some degree this strikes me as arguing "new for the sake of new". All the
things you describe can be accomplished with apt and yum if you can rely on
an sophisticated underlying filesystem. My contention is that we did NOT
need another entire design approach to software packaging just to accomplish
what you describe. It's just another annoyance to maintaining a large
environment.
There are lots of good ideas in IPS. I tend to evaluate tools on three
things:
Existance -- does the tool actually exist and work at all?
Sufficiency -- is is sufficient to provide the design function?
Necessity -- is it necessary to provide the design function, or can an
existing tool fill the same gaps?
I have no argument that IPS exists for a reason, and that it is sufficient
to satisfy a defined need. I question whether it was necessary.
Shrug. I just stated some design points that are functional
differentiators from other systems. They leverage features of our OS and
provide some attractive benefits.
--
Jeff Savit
Principal Field Technologist
Sun Microsystems, Inc. Phone: 732-537-3451 (x63451)
2398 E Camelback Rd Email: [email protected]
Phoenix, AZ 85016 http://blogs.sun.com/jsavit/
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
