Re: [cobalt-developers] Re: (OT) SPARCRaQ (cobalt-developers digest, Vol 1 #1392)

["E.B. Dreger" <eddy+public+spam@xxxxxxxxxxxxxxxxx>]

> Date: Sun, 24 Mar 2002 10:24:00 +0100
> From: System_FS <cobalt.lists@xxxxxxxxxxxxxxxxxxxxx>


> please try debian before saing that (howewer you are quite right
> if you are talking about upsteam packages, but the work of a serious
> distribution is exactly to put packages "with one another in mind")

I agree that Slackware and Debian are leaner and cleaner.  (Plus
I like the BSD feel of Slackware.)  But this does not change how
the individual packages are rather out of sync with one another.


> > Linux having /bin and /sbin binaries depend on dynamic linking is
> > stupid.
> 
> true, but there exists sash busybox-static e2fsck-static ...

Yes.  And, as much as I hate to display laziness... things like
that should be part of the default install.  (Sort of like I
think that all fs should be mounted _sync_ by default... let the
default be safe.)


> > For upgrades, cvsup and "make world" are your friends.
> 
> apt-get is even better (both for source and for binary upgrades).
> And yes, I use cvsupit and portupgrade on freebsd so I known of
> make world, ports and semi aotomated ways of doing that.

Hmmmm.  I've not used apt-get, so I'll not try arguing one way or
the other on that.


> > Thinks Windows and DLL Hell.
> 
> sorry but linux cannot be at this hell level (one *can* have different
> versions of librariers)

Yes.  It's not that bad yet.  Perhaps my analogy was wrong:  When
v1.2.3 of package A requires libwhatever.so.1.3.6 or newer, which
requires libsomethingelse.so.2.0.9 or newer, but v2.0.4 of pkg B
doesn't work right with libwhatever.so.1.3.4 or later...

I've just gotten spoiled by all being designed together as a
system.  It has the downside that one often can't pick and choose
individual library versions, but my sysadmin efforts as a whole
are lower and less stressful under BSD. :-)


> > SPARC ISA is much cleaner than the x86 ISA.
> 
> besides I tink that on non-x86 buffer overflows are less
> dangerous since such exploits usually try to execute memory areas 

Yes.  One can still trash pointers other than the stack return,
which can have bad side effects, but the classic "insert
malicious code and run it" doesn't work.

I'd forgotten about x86's lack of hw support for non-x pages
until about 18 months ago.  I was programming on FreeBSD/x86, and
wanted to force a page to non-executable.  Tested it by writing
some code to said page and jumping there... and it ran just fine,
sans faults.  D'oh!


> which, by *hardware* design, can be declared non-executable
> (There are *software* patches for Linux to try that, see for example
> the grsecurity.net project, and to use some kind of mandatory

IIRC, SolarDesigner released such a patch.  I'd have to go back
and reread the technical workings of it... I skimmed, but did not
read in detail.  A most cool hack. :-)


> access control about which you were talking some lines above, 
> see for example lids.org or the security enhanced
> linux project by NSA)
> 
> > As someone with eight years Linux experience and a paltry two or
> > three under BSD, I moved from Linux to BSD.
> 
> Wheen (and if) the debian on a bsd kernel project will be finished
> I will possibly move (almost) all my linux and FreeBSD machines to that.

I, too, wish to try that when released.


> For now I think that a mix of debian linux and [Free|Open|Net]BSD is a 
> reasonable choice for any experienced administrator. 

Agreed.  And there's also room for a hardware vendor's pet flavor
(Solaris, HPUX, AIX, DUNIX^H^H^H^H^HTru64, etc.) in the mix.  I
was merely explaining why I think that BSD is _better_ overall
than GNU/Linux.


> Y regret very much that Cobalt/Sun does not use the rpm porting
> of apt-get for software upgrades.

Can't comment on apt-get.  I'll have to check it out.


Eddy

Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
--

Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@xxxxxxxxx>
To: blacklist@xxxxxxxxx
Subject: Please ignore this portion of my mail signature.

These last few lines are a trap for address-harvesting spambots.  Do NOT
send mail to <blacklist@xxxxxxxxx>, or you are likely to be blocked.