[PLUG] Kernel restrictions

[Keith Lofstrom]

This might shade towards plug-talk, but I thought I should give reasons
why I was adamant about a 2.6.9 kernel.  Others might find this useful.

I am not a computer professional.  While I would enjoy spending full
time tweaking on new kernels and installing software, I am theoretically
a full-time chip designer, which in the heat of design can require an
80 hour a week commitment.  There are slack periods (like the one I am
in now) where I can work on upgrading computers and tracking long-standing
annoyances.  However, this slack period will end soon, and at the end
of it I must have a laptop with a stable software suite, while permitting
critical security-related upgrades.  A supported distro is a good way
to get there.

I run some professional ($$K) CAD tools for designing integrated circuits.
These are written around transistor models that are produced by fabs,
which are extremely complicated and very exacting.  The fabs usually
produce numbers for mostly-closed circuit simulation models (HSPICE
modified BSIM4) and for geometry testing (Mentor Calibre) which can
be read by a very small set of closed-source professional CAD tools.
Only a very few of those run under Linux, and they typically are 
targetted on distros like Redhat 5 and Redhat 7 (!!!!).  They often
run some nasty binary-only copy protection code.  It usually requires
an annoying amount of kernel tweaking to get them to run on something
more modern - the last time I tried this was with RH9.

Yes, there are some open source tools, but these are like TRS80 basic
compared to GCC in terms of capability.  You cannot read the wafer fab
data with them, they do not have the proprietary models.  There are
some capable open-source models (EKV, Philips) out there, but the
wafer fabs don't generate data for them.  At a conference last week,
I talked with a senior researcher from Philips, and even they don't
have the influence necessary to make fabs like TSMC and UMC (and IBM!)
produce data for the open models.  When that changes, I will get out
of the proprietary tools and into open ones very quickly.  Until
then, I still have chips to design.

I used to be a Redhat fanboy (7x 8x 9x) - the major upgrades were
fairly painless, and the up2date service took care of security
needs.  Then they started retiring distros early, while the
still-supported RHEL distros were pretty ancient and constrained. 
I tried Fedora Core, but the support for those distros vanish soon
after their initial release.  

Two well supported distros emerged from a recent search - SUSE, and 
the Redhat Enterprise Linux (RHEL)-derived Scientific Linux (SL). 
CENTOS was another RHEL derivative that looked interesting, but SL
has some full time staffers at Fermilabs and a commitment to keep
it updated approximately forever.  I gave SUSE a try first - it
installed cleanly, and their support is good.  However, the SUSE
universe is a little insular;  while they provide a large set of
near-bleeding-edge software, they don't update very well outside
their own community.  SL/RHEL had the edge there, but the decision
was close.  What pushed me firmly into SL is the close ties with
the Fedora project;  while I don't want to depend on the zero-
support-for-last-weeks-distro Fedora legacy support, the online
information that the Fedora debug process generates is awesome. 
If I have a problem with SL/RHEL4.2 , I can often find an answer
related to Fedora Core 3.  Yes, FC4 and FCt5 are more bleeding
edge, but I have a job to do.

So I now have an RHEL4.2 clone running.  It comes with a 2.6.9
kernel.  I could certainly install a 2.6.666 bleeding edge kernel,
and sometimes I may do that and set it up as a boot option, but
the SL folks won't be supporting it or providing security updates,
while I can get them for the 2.6.9 they do support .   Again, Murphy's
Law almost guarantees that I will need to do a critical security
update during an 80-hour-a-week design marathon, and that had better
be no more than a 30 minute download, patch, and reboot.  I can (and
do) run all sorts of crazy stuff on my experimental machine, but
I am as dependent on this production laptop as I am on my eyeglasses. 
No screwing around allowed.

Now, back to tweaking and debug.  netdump looks promising ...

Keith

-- 
Keith Lofstrom          keithl at keithl.com         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs