The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Larry McVoy <lm@mcvoy.com>
To: arnold@skeeve.com
Cc: tuhs@tuhs.org
Subject: Re: [TUHS] Technical decisions based on political considerations [was Re: AT&T Research]
Date: Thu, 23 Jul 2020 07:42:36 -0700	[thread overview]
Message-ID: <20200723144236.GK21077@mcvoy.com> (raw)
In-Reply-To: <202007230602.06N6243i013099@freefriends.org>

Amen to both comments.  Especially Intel, I'm so happy to not be
dealing with them.  Just an example, they used Netapp's mirroring
stuff - stuff that says in big bold letters "Mirrors are read only,
you may not write to them".  Of course they wrote to them and it 
didn't go well. 

They were using BitKeeper and they cloned a repo to a mirror.  
A clone in BK is basically

	( cd from; tar cf - . ) | (mkdir to; cd to; tar xf -; bk repocheck)

It is more complicated than that, it doesn't do a tar, it finds all the
SCCS files and transfers those and a handful of etc files.  And it has
a bill of materials file that lists all the SCCS files.  So a repocheck
is sort of like

	find . -name 's.*'  | check that list against the bill of materials

When we unpacked the files and went to go look for them, half the files
that we just wrote were "not there".  They were there but there were no
entries for them in the directory so it looked like they were not there.

Intel said that BitKeeper was broken.  For 3 months.  After I gave 
them scripts that replicated what BitKeeper was doing but had no
BitKeeper in them.  After tuning those scripts so their so-called
filer validation team could use them as a test system to verify
that the filers worked.

As a kernel guy, I did the most in depth work in file systems. I
know what I'm talking about.  But Intel said it was all Bitkeeper's
fault.  It wasn't, it was just that BitKeeper was the only application
they had that did integrity checks.

They finally backed down when I called Steve Kleinman who was CTO
at Netapp and my mentor at Sun, he immediately said yeah, I know,
it's us, that mirror shit sucks.  And he called Intel.

Intel is just an awful company.  I know they pay Clem's bills, go
Cleam, but Intel sucks.

On Thu, Jul 23, 2020 at 12:02:04AM -0600, arnold@skeeve.com wrote:
> scj@yaccman.com wrote:
> 
> > The technical people I met all seemed 
> > competent -- it must be the management that was the difference...
> 
> <rant>
> I saw this *a lot* when I worked at Intel; being forced to use
> the wrong tools for software development because of political
> considerations instead of technical ones.  One of the reasons I
> was super glad to leave there and why I think that Intel as a
> whole will never make it as a software company. (There are pockets
> there that understand software, but the majority of the company
> does not.)
> </rant>
> 
> Sorry,
> 
> Arnold

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

      reply	other threads:[~2020-07-23 14:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-11  1:08 [TUHS] AT&T Research John P. Linderman
2020-07-11  1:32 ` Larry McVoy
2020-07-11  1:51   ` John P. Linderman
2020-07-11 15:36 ` Clem Cole
2020-07-11 20:30   ` Warren Toomey
2020-07-11 20:36     ` Jon Steinhart
2020-07-11 21:58     ` Rob Pike
2020-07-11 22:29       ` Larry McVoy
2020-07-12  7:55         ` Ed Bradford
2020-07-12  2:22     ` [TUHS] BTL pranks [was AT&T Research] Doug McIlroy
2020-07-12 11:58       ` [TUHS] Monitoring by loudspeaker (was: BTL pranks) Michael Kjörling
2020-07-12 13:25         ` Dan Cross
2020-07-12 14:58         ` Robert Clausecker
2020-07-12 16:09           ` [TUHS] Monitoring by loudspeaker Al Kossow
2020-07-12 20:10             ` [TUHS] Fwd: " Rich Morin
2020-08-23  8:58           ` [TUHS] " Tom Ivar Helbekkmo via TUHS
2020-07-23  4:13     ` [TUHS] AT&T Research scj
2020-07-23  6:02       ` [TUHS] Technical decisions based on political considerations [was Re: AT&T Research] arnold
2020-07-23 14:42         ` Larry McVoy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200723144236.GK21077@mcvoy.com \
    --to=lm@mcvoy.com \
    --cc=arnold@skeeve.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).