[Sunhelp] SGML tools on Solaris7 or non-GNUified Solaris

[Gregory Leblanc]

I think I'm going to drag this out a little more, just to see how much
education I can get.  :)

> -----Original Message-----
> From: James Lockwood [mailto:lockwood at ISI.EDU]
> Sent: Monday, November 22, 1999 4:29 PM
> To: 'sunhelp at sunhelp.org'
> Subject: RE: [Sunhelp] SGML tools on Solaris7 or non-GNUified Solaris
> 
> 
> On Mon, 22 Nov 1999, Gregory Leblanc wrote:
> 
> > Can you be more specific?  So far, the only thing that 
> Solaris does better
> > than Linux is the filesystem, which is far better.  I'd 
> like to know where
> > you see the Solaris kernel being superior to Linux.
> 
> Off the top of my head:
> 
> More robust FS including journaling.
> Better (non broken!) faster NFS implementation.

I'm aware that NFS is broken on Linux, which is bad.  And of course faster
is always better, but I'm curious as to how extensively NFS is used, since I
don't work in a unix shop.  If I'd taken the time to read the NFS howto, I
might be using it on a couple of internal boxes, but I've heard that (rumor)
NFS is rather insecure.  It seems to me that it should be able to make it
secure, if it's like everything else on Unix, but I don't really know.  I
guess I need to do a bit more reasearch.

> Much better IP stack.

I haven't seen this to be the case.  At home, I can pull about 40KB/sec from
both my Linux box, and my Solaris box, over the same connection, which is a
384K DSL.  Windows 98 gets about 33-38, and NT usually gets 36-40.  But I
see very little difference in these two IP stacks.  The linux IP stack also
seems to have much more "added functionality" built in, so that you can do
things like QOS and MASQ with the kernel tools.

> Finer kernel granularity.
> Better kernel threading.

I don't understand kernel hacking yet, so I'll assume that those are "good
things" that Solaris does better than Linux.

> Fewer arbitrary limits (filesize, max open fd's, max memory, etc).

Well, the filesize limit is on it's way out, ext3 is running on a couple of
servers that I know of, with good results.  The ram limit isn't for Intel
hardware, since that's all the CPUs can address, except maybe the Xeon.  On
SPARC this may be more of a problem, since they can easily handle much more
RAM on a modern CPU than x86 can.  

> Stable driver interface (through the DDI).

I thought that the drivers for linux were generally pretty good, but I
suppose I could be in error.  PCMCIA is maintained as a separate package
from the kernel, and runs exclusively as modules.  That package seems to be
at least as good as the one on MS, though I haven't tried Solaris on a
PCMCIA computer yet.  That's the only example that I have, except that DPT
(PC-RAID, and I hear this is what sun is using) writes their drives as a
simple kernel patch.  I guess I need to take a few programming courses,
since I'm only familiar with procedural programming, which doesn't make code
that looks like what I've read.

> Useful OpenGL/GLX (only on SPARC).
> API's that don't change when you blink.
>  
> Some of these are tradeoffs at both ends of the spectrum.  The higher
> kernel granularity in Linux is a win on one or two CPU 
> desktop boxes and
> still wins for syscall latency on big boxes (what the Linux crowd is
> always bragging about) but syscall throughput is seriously 
> affected.  Not
> too much of a hit for a desktop box, but bad for a large 
> database server. 
> 
> Since Solaris has been increasingly positioned as a server OS, the
> tradeoffs have been made in the other direction.  It has a larger
> footprint and more overhead, but scales better.

I don't suppose that these sort of things could be either kernel load time,
or kernel compile time tweakable?  If they could then perhaps that might be
a direction to point the linux kernel, although I have only a fringe
knowledge of this, again.

> 
> > How?  I'm a power user on Linux, but barely a normal user 
> on Solaris right
> > now.  But I still don't see big differences in those tools, 
> except that I
> > can't build SGMLTools with the versions that shipped with 
> Solaris.  :)
> 
> This is the dark side of Linux and GNU.
> 
> There is little to no reason to require gcc or gmake or gtar 
> to build a
> software package. Nearly anything that they do "GNU style" can be done
> portably. 

Cool!  That's what I wanted to hear.  :)

> 
> The problem is that there are a whole wave of programmers out 
> there whose
> only exposure to Unix has been through the free PC Unices, 
> which tend to
> use the same set of tools with the same extra features added. 
>  They use
> these extra features without regard to portability, and don't bother
> testing their packages on other systems.  To many of them, a software
> package is portable when it builds on both Redhat and Debian 
> Linux.  Some
> of the fringe groups might test on FreeBSD as well.
> 
> I don't know if SGMLTools is a victim of this trend, but I 
> hope it isn't.
> The GNU software packages are marvelous things and truly an 
> asset to the
> software community, but there has been some build environment 
> fragmentation just as there was/is with Netscape and HTML.

It sounds to me like it is, and since it's "no longer maintained" I don't
seem to be getting the kind of help that I'd like to from the list.  One
person who has responded, told me to try the GNU-tools.  The gnu tar works,
but make still fails. :(  As long as I'm asking, do you(general populace,
that is) think that volunteering to build/run/document these gnu-ified
projects on other OSs will make a difference?  I'd really like to see good
things like these tools running on Solaris and *BSD and AIX and whatever
else, since I believe them to be good pieces of work.  SGMLtools is what I
was/am going to try to use on the Hardware FAQ to get output into other
formats like text and post-script, but I don't want to have to stay extra
hours at the office to do it.  

> Those who do not remember Unix are doomed to reinvent it, poorly.
> 
> Sorry for the rant.

C'mon, these rants are a good thing, especially with the nice technical side
that yours had.  I tend to rant quite easily myself, and don't have near the
technical understand that you do.  Thanks,
	Greg