On 3/26/09 2:13 PM, "Jeff Savit" <jeff.sa...@sun.com> 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.

> 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.
 
> 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=78357&tstart=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-)

>> They have been trying rather diligently to clean up the mess around these
>> 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 like
>> 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.

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

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

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. 

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to