Is Yahoo! moving from FreeBSD?

[Ted Mittelstaedt]

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Julien Gabel
> Sent: Thursday, February 24, 2005 8:54 AM
> To: Ted Mittelstaedt
> Cc: questions at freebsd.org
> Subject: Re: Is Yahoo! moving from FreeBSD?
>
>

>
> Yes, i do.  This is one of the aim of this initial fork of the FreeBSD
> ports collection (pkgsrc) to be used on multiple plateform and
> operating
> system (NetBSD, Solaris, Linux, AIX, etc.: a list of all the supported
> OSes can be found at http://www.pkgsrc.org/).  Sure, it is not perfect,
> but it is a valuable tool.
>

Interesting, I wasn't aware that pkgsrc was aiming to be cross-platform.

> Because sunfreeware.com provide binary only packages for Solaris, it is
> very convenient to be able to compile our own set of packages
> from source
> (and use our particular settings) or be able to install a software not
> provided on sunfreeware.com or not yet updated.
>
> It can then be possible to track and keep a real personalized
> third party
> software baseline on multiple release versions of one or more OSes (for
> example, have the same version of compilation tools or web server on
> Solaris 2.6, Solaris 9 and Linux).
>
> I don't think _one_ tool can solve of all problems, but use both the
> native and non-native (pkgsrc) tools/package manager can be a good
> compromise.
>
> The advantages i think of (at least :-))
>   - As with the FreeBSD ports collection, we can use an
> existing base of
>     packages building from source (generally well up-to-date)
> with our own
>     settings;
>   - Management of software (or tools) dependancies;
>   - Automatic checking for security vulnerabilities in
> installed packages;
>   - Can generate binary package from our own sets, either manually or
>     automatically using the bulk builds (for deployment for example);
>   - Although compiled from source, you can managed installed
> packages via
>     the pkg_* tools which is more convenient than from hands
> in /usr/local;
>   - Don't interfer with supported native packages (from Sun) or non-
>     supported packages (from sunfreeware.com, etc.).
>
> As a side note, it is interesting to note that although not
> considered part
> of Solaris 10 you can found a _reference_ to the The NetBSD Packages
> Collection on the Compagnion CD provided by Sun[1], among
> others.  It would
> seems furthermore than there exists a specialized group in the NetBSD
> Project to handle specific PRs on this plateform
> (solaris-pkg-people) and
> that Sun will be using "some form of pkgsrc" for its contrib packages
> extras in Solaris[2] (i have not yet verify this).  Last, Sun has
> contributed
> some hardware to help making bulk builds of pkgsrc on Solaris OS[3].
>
> >> I don't say i disagree with your global point of view, just that the
> >> last two points may be slightly... moderated :)
>
> > Solaris 2.6, 8, 9, 10 don't run on EISA.  They also got rid of the
> > alt-F keys for the multiple consoles.
>
> Yes, right :(
>
> > 2.6 also included it's own perl, and I think later versions did too.
> > Blech on that if you needed a later version of perl on the system.
>
> On Solaris 10 plateform, you can found Perl 5.8.4 and Perl 5.6.1.  The
> default is to place Perl 5.8.4 as /usr/bin/perl.
>
> > These Solaris versions were fine for big companies with lots
> of money to
> > buy brand new Sun boxes (which ran them well).  They were
> hideous for not
> > so big companies that didn't want to have to throw perfectly
> good quad
> > Pentium 200 servers with EISA hardware raid controllers and big SCSI
> > arrays on them in the garbage.
>
> Maybe we can hope this will change in near future, with Solaris 10+.
>

Oh, it's going to change eventually.  Despite all Intel's work there is
a practical limit to CPU speeds.  Ultimately the desktop PC architecture
is going to come to a halt in terms of speed increases, and will remain
there unless the entire architecture is chucked out and replaced with
something else (optical, perhaps?)

Once that happens, software vendors will not be able to count on the
increasing hardware speed making up for the shortcomings of their
4GL tools or scripts, or whatever quick hacked tools are that spew
forth such bloated code.

At that time, even throwing money into new hardware won't speed up
the next version of whatever application is sold.  Customers are
going to force the ISV's into hand optimization, better yacc's,
etc.

> > And try building something like ImageMagik on Solaris 10 I will bet
> > that at least 1 of the collection of libraries that this conglomerate
> > program requires will not build without tweaks.
>
> Certainly.  (FYI: currently, it breaks on the graphics/jasper
> dependancy
> on the 2004-Q4 branch)

Hmm - jasper builds on my solaris box

Ted