From: Toon Moene on
Morten Reistad wrote:

> From my observations of Linux, Linux is pretty infected
> with the problems of low quality fixes, blob support, bloat,
> eye candy before sunstance, and blatant insecurity.

I wasn't aware that there was eye candy in the Linux kernel. At least
until my Debian testing bootup says: "Starting xdm." I have seen nothing
but straight, large (i.e., readable without glasses to my aging eyes)
characters.

--
Toon Moene - e-mail: toon(a)moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Who's working on GNU Fortran:
http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
From: Steve O'Hara-Smith on
On Sun, 01 Apr 2007 01:39:04 -0500
Charles Richmond <frizzle(a)tx.rr.com> wrote:

> CBFalconer wrote:
> > Nick Maclaren wrote:
> >> Morten Reistad <first(a)last.name> writes:
> >>> Lastest pc press blurbs. Vista only runs around 80 of 150
> >>> identified critical XP applications.
> >> Hasta la vista?
> >
> > No, Vista hasta go sista.
> >
> It's just *another* Mi$uck mess... What can we expect???
> This is their idea of innovation.

Indeed, soon there will be new versions of the other 70 that will
work on Vista but will not work on XP, 2000, ME, 9x and so forth. These new
versions will have new features so the old versions won't reliably read
files from the new versions thus forcing updates to the new versions and
therefore Vista. This is a painfully familiar pattern that has been reused
over and over again going back (at least) to the move to Windows versions
of DOS software.

--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/
From: krw on
In article <euo48m$8qk_004(a)s910.apx1.sbo.ma.dialup.rcn.com>,
jmfbahciv(a)aol.com says...
> In article <MPG.207840b219666d1b98a273(a)news.individual.net>,
> krw <krw(a)att.bizzzz> wrote:
> >In article <eulkcd$8qk_008(a)s911.apx1.sbo.ma.dialup.rcn.com>,
> >jmfbahciv(a)aol.com says...
> >> In article <MPG.2077890e34e0efbb98a26e(a)news.individual.net>,
> >> krw <krw(a)att.bizzzz> wrote:
> >> >In article <460d9c5a$0$1428$4c368faf(a)roadrunner.com>,
> >> >Peter_Flass(a)Yahoo.com says...
> >> >> jmfbahciv(a)aol.com wrote:
> >> >> > In article <euggeu$92m$1(a)gemini.csx.cam.ac.uk>,
> >> >> > nmm1(a)cus.cam.ac.uk (Nick Maclaren) wrote:
> >> >> >
> >> >> >>In article <eugf8g$8qk_003(a)s879.apx1.sbo.ma.dialup.rcn.com>,
> >> >> >>jmfbahciv(a)aol.com writes:
> >> >> >>|>
> >> >> >>|> It could be the way DEC tracked the sales. PDP-10 product line
> >> >> >>|> never got any "credit" for all the minis it sold.
> >> >> >>
> >> >> >>I was actually thinking from the customer end, but cannot say which
> >> >> >>was the chicken and which the egg.
> >> >> >
> >> >> >
> >> >> > Neither could DEC managmeent and their bean counters. They ended
> >> >> > up ignoring that (I can never remember the correct value) somewhere
> >> >> > between 60-70% of the mini customers also had at least one PDP-10.
> >> >> > Most had more.
> >> >> >
> >> >>
> >> >> IBM had and has this problem too. Maybe there's just no way to quantify
> >> >> it sufficiently for the MBAs that look at this stuff. Many times I've
> >> >> seen them cancel a product that probably sold lots of other stuff with
> it.
> >> >>
> >> >We constantly were up against that problem in the crypto group. We
> >> >could point to systems that wouldn't have been sold were it not for
> >> >ICRF (take-aways from Hitachi, IIRC) but the CPU sales team claimed
> >> >them. Since our profits were minimal (intended as a differentiator)
> >> >we were up against cancelation every six months or so. When the
> >> >layoffs came to the Hudson Valley ('93) we were rather nervous (we
> >> >were spared for some unknown reason and I found a life raft to the
> >> >frozen North).
> >> >
> >>
> >> Yup. And think of all the funcking money spent trying to cancel
> >> and then justify keeping the group around. You could have "made"
> >> millions more by simply not discussing it.
> >
> >In the end, the reason we (all ten of us) were allowed to live is
> >that we had a few large customers who swore on a stack of bibles
> >they'd never buy another CPU from IBM if they pulled support. They'd
> >buy Amdahl first (the knife in the heart ;-).
> >
> We had quite a few of those. Our woodenheadedness finally wore them
> out.

They had an unlimited supply of wood in their heads. I moved to BTV;
far simpler.

--
Keith
From: John Byrns on
In article <1175381538.964435.181470(a)n59g2000hsh.googlegroups.com>,
"Quadibloc" <jsavard(a)ecn.ab.ca> wrote:

> David Kanter wrote:
> > On Mar 5, 5:20 am, "Quadibloc" <jsav...(a)ecn.ab.ca> wrote:
>
> > > Struggling with many opcode formats with which I was not completely
> > > satisfied in my imaginary architecture that built opcodes up from 16-
> > > bit elements, I note that an 18-bit basic element for an instruction
> > > solves the problems previously seen, by opening up large vistas of
> > > additional opcode space.
> >
> > Why is 18 bits any better than 32 bits?
>
> Well, 18 bits is less bits than 32 bits, but it's more bits than 16
> bits. So, if 16 bits aren't enough, jumping to 18 may get me what I
> want while using fewer transistors.
>
> However, further thought has led me to modify my page further, and add
>
> http://www.quadibloc.com/arch/per01.htm
>
> where I show it might be possible to build instructions out of units
> 12 bits long, to economize on RAM, without giving much up. (Of course,
> the PDP-8, and more especially the FPP-12, could be cited as
> precedents here.)


Your 12-bit long memory units are an interesting alternative to the
traditional 8-bit byte orientation. I am curious about several of the
design decisions you made in the design of your 12-bit orientated
instruction set.

1. When a register is used for indexing, why do only 15 of the 36 bits
in the register participate in the address calculation?

2. Why did you restrict the use of the indexed addressing mode to only
those instructions that target operands in the first register?

3. Why did you choose 36-bits as the general register size, when using
say 24-bits would save transistors?

4. Aren't three distinct floating point formats overkill, wouldn't two,
or even only one be enough?

After some thought I came up with a tentative instruction set, based on
your 12-bit proposal, which would address these issues. The changes can
be seen on this page:

http://fmamradios.com/arch12.html

I have not yet added the non-memory reference instructions, I will
complete the page in the next couple of days.

Further thought has led me to another more interesting and powerful
12-bit orientated instruction set, with a completely different
instruction style, which addresses the issues raised above, as well as
accommodates all three of your floating point formats, all while
providing greater flexibility in the use of the instruction set. I will
work on a page describing this more complex 12-bit instruction set once
I finish up the first page.


Regards,

John Byrns

--
Surf my web pages at, http://fmamradios.com/
From: Anne & Lynn Wheeler on
Morten Reistad <first(a)last.name> writes:
> From sharing of segments, startup of databases, startup of deamons
> for network, transactions, necessary initialisations of these,
> rollback/forward, various spoolers, etc.
>
> The Tops20 installation I got to know took 17 minutes from load to
> usefulness; it was a 2065. A primos-based Prime 4450 (approx 5 mips)
> took 27 minutes to get up to speed. This was a transaction system
> that distributed live data to lots of clients, and had most of it
> in RAM, with sources in databases.

cp67 took a couple minutes in the late 60s ... that also was time for
automatic restart simulated load after (soft) failure.

here is tale about some people at mit having experience with both cp67
and multics in that period ... and the multics coming off very poorly in
comparison ... eventually resulting in recoding sections of multics to
try and make it more favorable comparison.
http://www.multicians.org/thvv/360-67.html

it was highlighted by a local cp67 kernel change that resulted in 27
failures/auto-restarts in a single day ... where multics wouldn't have
been able to even come close to that number ... just because of the
lengthy restart time.

i was partially to blaim for that occurance. As an undergraduate I had
added the tty/ascii support for cp67 (base system support 2741 and
1052). I had played some games in the code with truncating line-length
calculations to one byte. The cp67 service running at MIT wanted to add
support for some sort of simulated ascii terminal device over at harvard
(plotter?) which had max. line length more like 1200 bytes. Their kernel
patch updated some constants for maximum line length ... w/o changing
the code that played games with 1byte truncation (which then resulted in
some incorrect lengths being calculated and subsequent sotrage
overlays).

the science center (responsible for cp67) was on the 4th flr
of 545 tech sq.
http://www.garlic.com/~lynn/subtopic.html#545tech

the science center 360/67 machine room was on the 2nd flr and multics
was on the 5th flr.

My recollection was that the MIT Urban systems lab (and their 360/67,
where the referenced cp67 story takes place) was across the tech. sq
courtyard in 5?? tech sq.