On Sun, 15 Oct 2023 13:47:19 -0500, BGB <cr88192@gmail.com> wrote:

>On 10/15/2023 12:36 PM, George Neuner wrote:
>
>> There are exceptions, but "string" like fields should (almost) never
>> be the /primary/ key or used for a foreign key. However, it does make
>> sense to be able to index them effectively for searching.
>>
>
>Yeah.
>
>I guess, if I were designing something, likely integer fields would be
>used for primary keys (or index keys, if the primary key is not an
>integer type).

For a while now, I've been using UUID v1 for primary keys because they
can be time sorted (useful for log structured tables), and because in
a distributed database, separate shards can be merged without worrying
about conflicting primary keys.
[Obviously you must consider any /other/ keys on the table.]

>Possibly, secondary index B-Tree's could either map string fields to the
>index key/primary key; and also for implementing foreign keys, ...
>
>
>Less sure how one would go about efficiently implementing queries by
>non-unique fields though, say:
> select * from Workers where FirstName='James'
>Or similar...
>
>In a naive implementation, something like this would likely require
>walking every row in the table to perform the query.

Strings, in general, require an index that supports "multiset".

The actual strings obviously are needed, but unique strings can be
stored just once in a (compiler style) "interning" table associated
with the index. Additionally the strings can be hashed to create
integer search keys to accelerate "exact" match searches.

>Otherwise, one would likely need to build lists of rows which have a
>given field row, or alternatively use hash-chains or similar in addition
>to B-Trees. Would need to come up with a hash-chain structure that deals
>well with arbitrary scalability. One could possibly build hash-chains on
>top of a B-Tree, but this seems inefficient (say, one builds a
>linked-list for each hash-chain segment on top of a B-Tree, with each
>segment containing 0..N index keys for rows where this field matches the
>corresponding hash).

A (compiler style) interning table to store the unique strings in the
index usually is a good idea.

Using auxiliary data structures for rowsets is more complicated: you
need to maintain a separate rowset for each unique string, the rowsets
typically will be modified much more frequently than the string table,
the rowsets will be differently sized (set cardinality), and they will
need to be kept sorted to be useful for row fetching.

If you use a search method that naturally supports multisets - e.g.,
hash table or B+tree - then you can just keep the individual row
references right in the index entries, and construct a sorted list as
you locate matching entries. It costs some space, but makes
maintaining the rowsets much less complex.

Just in general you don't want your index to be in lots of little
pieces because that will complicate persisting it to disk. You want to
use structures that are simple to serialize: trees and lists
implemented by arrays of fixed size records, offsets instead of
pointers, etc.
[Not telling you anything you don't already know. 8-)]

In any case, exact matches and even many function-of(string) matches
can be handled relatively easily because the interned strings can be
hashed. The index keys then become a pair { hash, string-ref }, which
makes each entry a bit larger, but avoids dealing with character data
unless you first match the hash.

It is partial and dynamic matching: wildcards, regex, etc., that is
the real problem for indexing. These kinds of searches have to go
straight to the character data. They are brute force with the only
savings from indexing coming from reduced I/O: scanning the index vs
scanning the (presumably much larger) source table.

>But, yeah, in terms of the CPU, still it seems like all this mostly
>amounts to designing the CPU mostly to optimize for large working sets;
>rather than any particular ISA feature (say, the typical SIMD
>shenanigans or similar; where things like floating-point SIMD are
>unlikely to be particularly useful for database workloads, ...).
>
>...

Typical server workloads.

George

On 10/13/23 10:17, Marco Moock wrote:
> Hello!
>
> Fujitsu´s roadmap shows 2029 as end of sale and 2034 as end of support
> of their SPARC product line.
>
> Do other vendors like Oracle still continue to sell them or is SPARC
> dead?
>

The end of an age, and of a revolution. Learned so much from having and
using Sun machines, for nearly three decades. I guess no general purpose
computing company can match the tech prowess of Intel at squeezing the
last drop of performance from their processors.

Shut down the last Sparc machine here at the end of last year. Too slow
and too much power consumption, sadly...

Chris

On Sat, 21 Oct 2023 23:28:57 +0000
chrisq <devzero@nospam.com> wrote:

> On 10/13/23 10:17, Marco Moock wrote:
> > Hello!
> >
> > Fujitsu´s roadmap shows 2029 as end of sale and 2034 as end of
> > support of their SPARC product line.
> >
> > Do other vendors like Oracle still continue to sell them or is SPARC
> > dead?
> >
>
> The end of an age, and of a revolution.

Revolution? Can you elaborate?

> Learned so much from having
> and using Sun machines, for nearly three decades. I guess no general
> purpose computing company can match the tech prowess of Intel at
> squeezing the last drop of performance from their processors.
>

Not really.
Apple and AMD are very close to Intel's best in absolute single-thread
performance and both are better than Intel in performance per Watt. In
case of Apple, a lot better.
AMD also beats Intel in throughput per socket and throughput
per price.
Qualcomm promises to match Intel in absolute single-thread
performance really soon. And there are reasons to believe them.
Ampere beats Intel in throughput per socket and throughput
per price. They are behind in single-thread speed, but not ridiculously
so. Their single-thread performance is adequate for majority of uses.
The same applies to Amazon's Graviton processors. They don't sell
them so are not direct competitors. But they compete indirectly for
places in AWS racks.
IBM leads everybody else in throughput per core which is very important
ratio for people that by expensive software that is licensed per core.
Their single-thread performance is likely close to that
of Intel/AMD/Apple but they don't publish relevant benchmarks so it's a
guess rather than fact.

In other words, everybody who is still willing to compete is able to
outperform Intel in at least one metric.
Oracle and Fujitsu lost due to their own unwillingness to fight.

> Shut down the last Sparc machine here at the end of last year. Too
> slow and too much power consumption, sadly...
>
> Chris
>

On 2023-10-22, Michael S <already5chosen@yahoo.com> wrote:
> On Sat, 21 Oct 2023 23:28:57 +0000
> chrisq <devzero@nospam.com> wrote:
>
>> On 10/13/23 10:17, Marco Moock wrote:
>> > Hello!
>> >
>> > Fujitsu´s roadmap shows 2029 as end of sale and 2034 as end of
>> > support of their SPARC product line.
>> >
>> > Do other vendors like Oracle still continue to sell them or is SPARC
>> > dead?
>> >
>>
>> The end of an age, and of a revolution.
>
> Revolution? Can you elaborate?
>
>
>> Learned so much from having
>> and using Sun machines, for nearly three decades. I guess no general
>> purpose computing company can match the tech prowess of Intel at
>> squeezing the last drop of performance from their processors.
>>
>
> Not really.
> Apple and AMD are very close to Intel's best in absolute single-thread
> performance and both are better than Intel in performance per Watt. In
> case of Apple, a lot better.
Put Apple ARM on same frequency as Intel, and you will see single
threaded performance...

>

--

7-77-777, Evil Sinner!
https://www.linkedin.com/in/branimir-maksimovic-6762bbaa/

On 10/22/23 11:57, Michael S wrote:
> On Sat, 21 Oct 2023 23:28:57 +0000
> chrisq <devzero@nospam.com> wrote:
>
>
>> The end of an age, and of a revolution.
>
> Revolution? Can you elaborate?
>
>

Perhaps more than any other, Sun were at the leading edge of putting
serious technical computing on desktops. Affordable desktop unix
sounded the death knell of minicomputer manufacturers like DEC.
Companies like Charles River Data Systems were early 68K unix vendors,
but never reached the critical mass that Sun managed.

Compare the capability of even a Sun 3 with the state of the art in
pc tech at the time...

Chris

On Mon, 23 Oct 2023 14:23:10 +0000
chrisq <devzero@nospam.com> wrote:

> On 10/22/23 11:57, Michael S wrote:
> > On Sat, 21 Oct 2023 23:28:57 +0000
> > chrisq <devzero@nospam.com> wrote:
> >
> >
> >> The end of an age, and of a revolution.
> >
> > Revolution? Can you elaborate?
> >
> >
>
> Perhaps more than any other, Sun were at the leading edge of putting
> serious technical computing on desktops. Affordable desktop unix
> sounded the death knell of minicomputer manufacturers like DEC.
> Companies like Charles River Data Systems were early 68K unix vendors,
> but never reached the critical mass that Sun managed.
>
> Compare the capability of even a Sun 3 with the state of the art in
> pc tech at the time...
>
> Chris
>

In that sense, "serious technical computing" still often done on
desktop, although probably not as much as it was 20-25 years ago.
And it could be said that Sun was the first that started to turn
the wheel in the opposite direction with their "network is a computer"
motto. That's what turned the "revolution" backward and brought
majority of "serious technical computing" back to server rooms behind
the closed doors, into modern days equivalents of minis. And in
more recent years even further back, to cloud, i.e. modern days
equivalents of mainframe and service bureau.
Ultimately, Sun Microsystems was not a beneficiary of reversed trend,
but that were they that started it, and it were they that put their
weight behind it for majority of their 28-years corporate history.

On 10/23/2023 11:15 AM, Michael S wrote:
> On Mon, 23 Oct 2023 14:23:10 +0000
> chrisq <devzero@nospam.com> wrote:
>
>> On 10/22/23 11:57, Michael S wrote:
>>> On Sat, 21 Oct 2023 23:28:57 +0000
>>> chrisq <devzero@nospam.com> wrote:
>>>
>>>
>>>> The end of an age, and of a revolution.
>>>
>>> Revolution? Can you elaborate?
>>>
>>>
>>
>> Perhaps more than any other, Sun were at the leading edge of putting
>> serious technical computing on desktops. Affordable desktop unix
>> sounded the death knell of minicomputer manufacturers like DEC.
>> Companies like Charles River Data Systems were early 68K unix vendors,
>> but never reached the critical mass that Sun managed.
>>
>> Compare the capability of even a Sun 3 with the state of the art in
>> pc tech at the time...
>>
>> Chris
>>
>
> In that sense, "serious technical computing" still often done on
> desktop, although probably not as much as it was 20-25 years ago.
> And it could be said that Sun was the first that started to turn
> the wheel in the opposite direction with their "network is a computer"
> motto. That's what turned the "revolution" backward and brought
> majority of "serious technical computing" back to server rooms behind
> the closed doors, into modern days equivalents of minis. And in
> more recent years even further back, to cloud, i.e. modern days
> equivalents of mainframe and service bureau.
> Ultimately, Sun Microsystems was not a beneficiary of reversed trend,
> but that were they that started it, and it were they that put their
> weight behind it for majority of their 28-years corporate history.
>

Sort of half reminds me:
Sometime, roughly 20 years ago, had encountered something Sun related
(in one of the classes I was taking at the time).

IIRC, it looked like a flat-panel LCD monitor with a keyboard and mouse
plugged into it, with an Ethernet cable.

IIRC, the screen had a big Sun Microsystems logo, and I think also the
name Sun Microsystems next to the logo, taking up the top part of the
screen, with the lower part of the screen then having a username text field.

Looking stuff up, the "Sun Ray 150 Thin Client" looks most like the
thing in my memory.

Though, never saw it in use and never used it, was just sort of there...

Was a bit of a curiosity though, since this was mostly still in the era
of beige tower PCs with CRT monitors (this was shortly before I had
built a PC with a then-new x86-64 Clawhammer CPU; still using a big CRT
though).

Never saw any Sun workstations though; IIRC, at the time, they were most
well known for things like the Java JVM and similar.

....

Ironically, did see a video recently where someone was showing off a Mac
clone (which sort of resembled a Mac/PC hybrid, using a fairly
conventional 90s PC style case; including the whole thing of using a
riser so that they could put the PCI cards sideways, which is luckily
sort of a thing that mostly went away; also had a weird MOBO and used
SCSI drives), which is another thing I had never seen.

Last Macs I really saw IRL were mostly members of the "Macintosh II"
line, before they seemingly disappeared almost entirely (the world going
otherwise pretty much exclusively to Windows based PCs).

....

In other news: Did "mostly" achieve my "get stuff running at 75MHz"
goal, though just barely, and it is still rather prone to fail timing
seemingly at random.

Did resort to some "weird hacks", like moving part of the logic for
determining instruction length into the cache-line "store into L1 array"
stage, which means L1 I$ cache lines are now specific to the ISA mode
that was in effect at the time the cache-line was fetched (from memory).

Still seems possibly like my instruction encodings are "pushing it" for
a 75MHz CPU core, as things related to instruction length and decoding
were a big part of this part of the battle (and did end up making some
amount of structural changes to the instruction decoder, ...).

Does make me half wonder though if a "cleaned up" design for the CPU
core and ISA could maybe push everything (with a similar feature set to
my existing ISA) to 100MHz (well, excluding the FP-SIMD unit; which
still seems to fall a bit short of being able to pass timing as-is).

Though, could maybe make sense to add a few more EX stages, say:
EX1/2/3, As-is
EX4, "Hidden" stage (no forwarding).
EX5, Final EX stage
WB
With available instruction latency of: 2, 3, and 5 cycles (possibly with
a special case hack to still allow for single-cycle register moves and
constant loads). Then use 5-cycle ops for things like Binary32 FPU and
SIMD, given 3-cycle isn't really working out at the moment.

Also, turns out my branch predictor is broken and has likely been broken
for quite a while now (leaving a possible sub-goal of being to be able
to get the branch predictor to "actually work").

....

Michael S <already5chosen@yahoo.com> writes:
>On Mon, 23 Oct 2023 14:23:10 +0000
>chrisq <devzero@nospam.com> wrote:
>
>> On 10/22/23 11:57, Michael S wrote:
>> > On Sat, 21 Oct 2023 23:28:57 +0000
>> > chrisq <devzero@nospam.com> wrote:
>> >
>> >
>> >> The end of an age, and of a revolution.
>> >
>> > Revolution? Can you elaborate?
>> >
>> >
>>
>> Perhaps more than any other, Sun were at the leading edge of putting
>> serious technical computing on desktops. Affordable desktop unix
>> sounded the death knell of minicomputer manufacturers like DEC.
>> Companies like Charles River Data Systems were early 68K unix vendors,
>> but never reached the critical mass that Sun managed.
>>
>> Compare the capability of even a Sun 3 with the state of the art in
>> pc tech at the time...
>>
>> Chris
>>
>
>In that sense, "serious technical computing" still often done on
>desktop, although probably not as much as it was 20-25 years ago.

When the Sun-1 came out in the 80's, the bulk of
technical computing was done on minicomputers (e.g. VAX)
using graphical output devices like the 4014 and VK100 GIGI.

In article <uh6atm$39euq$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:

> Looking stuff up, the "Sun Ray 150 Thin Client" looks most like the
> thing in my memory.
>
> Though, never saw it in use and never used it, was just sort of
> there...

A guy from Sun came to my employer about that time to promote them to us.
We had no use for them, and it seems not many people did. The days of X
terminals were brief, and pre-dated the RISC revolution.

> Never saw any Sun workstations though; IIRC, at the time, they were
> most well known for things like the Java JVM and similar.

We had a fair few Sun workstations for building and testing software at
the time. We dropped the platform about 2018.

John

On 10/23/2023 2:52 PM, John Dallman wrote:
> In article <uh6atm$39euq$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:
>
>> Looking stuff up, the "Sun Ray 150 Thin Client" looks most like the
>> thing in my memory.
>>
>> Though, never saw it in use and never used it, was just sort of
>> there...
>
> A guy from Sun came to my employer about that time to promote them to us.
> We had no use for them, and it seems not many people did. The days of X
> terminals were brief, and pre-dated the RISC revolution.
>

This was around 2003 or so IIRC.

Granted, I am not entirely sure the point of having a thin terminal,
when one also has PC's. Also never actually saw anyone using it for
anything, was just sort of hanging out in one of my classes as a bit of
a novelty.

This was also in the days when Windows XP was new and shiny, but the
use-case for a PC running Windows XP was a bit more obvious.

>> Never saw any Sun workstations though; IIRC, at the time, they were
>> most well known for things like the Java JVM and similar.
>
> We had a fair few Sun workstations for building and testing software at
> the time. We dropped the platform about 2018.
>

OK.

Did they keep getting made after Oracle bought Sun?...

But, if any were around, wherever they were, they were not anywhere near
any of the high-school students.

....

Some time later, when taking some college classes (after moving to
Guam), they were using an AS/400 somewhere. It was not uncommon to see
teachers and other people doing data-entry tasks in a terminal emulator
with a characteristic white-on-blue text interface.

IIRC, according to one of the teachers, somewhere on campus there was I
guess a twinax to ARCNET bridge, where apparently ARCNET was used for
the on-campus network (as opposed to Ethernet). Whole thing seemed kinda
weird and crufty at the time.

This being sometime around the 2006/2007 timeframe...

BGB <cr88192@gmail.com> writes:
>On 10/23/2023 2:52 PM, John Dallman wrote:
>> In article <uh6atm$39euq$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:
>>
>>> Looking stuff up, the "Sun Ray 150 Thin Client" looks most like the
>>> thing in my memory.
>>>
>>> Though, never saw it in use and never used it, was just sort of
>>> there...
>>
>> A guy from Sun came to my employer about that time to promote them to us.
>> We had no use for them, and it seems not many people did. The days of X
>> terminals were brief, and pre-dated the RISC revolution.
>>
>
>This was around 2003 or so IIRC.
>
>Granted, I am not entirely sure the point of having a thin terminal,
>when one also has PC's. Also never actually saw anyone using it for
>anything, was just sort of hanging out in one of my classes as a bit of
>a novelty.

We used NCD X-terminals extensively from 1989 through 1997,
connected to Unix servers (mostly 88100-based MVME or Unisys
S/8400 systems).

PCs were not viable alternatives in that era.

On 10/23/2023 3:59 PM, Scott Lurndal wrote:
> BGB <cr88192@gmail.com> writes:
>> On 10/23/2023 2:52 PM, John Dallman wrote:
>>> In article <uh6atm$39euq$1@dont-email.me>, cr88192@gmail.com (BGB) wrote:
>>>
>>>> Looking stuff up, the "Sun Ray 150 Thin Client" looks most like the
>>>> thing in my memory.
>>>>
>>>> Though, never saw it in use and never used it, was just sort of
>>>> there...
>>>
>>> A guy from Sun came to my employer about that time to promote them to us.
>>> We had no use for them, and it seems not many people did. The days of X
>>> terminals were brief, and pre-dated the RISC revolution.
>>>
>>
>> This was around 2003 or so IIRC.
>>
>> Granted, I am not entirely sure the point of having a thin terminal,
>> when one also has PC's. Also never actually saw anyone using it for
>> anything, was just sort of hanging out in one of my classes as a bit of
>> a novelty.
>
> We used NCD X-terminals extensively from 1989 through 1997,
> connected to Unix servers (mostly 88100-based MVME or Unisys
> S/8400 systems).
>
> PCs were not viable alternatives in that era.
>

Yeah... But, if it were from the 1989..1997 timeframe, I don't expect it
would have been using a full color LCD flat-panel display...

This was still fairly new tech at the time... and mostly limited to
things like laptops.

Granted, these sorts of LCD displays mostly replaced CRTs over the
following years.

Like, seemingly, someone, in around 2002 (apparently when this model
went on the market), thought getting these terminals was a good idea.

Or, if it was an older installation, I would have expected CRT based
terminals.

....

> Granted, I am not entirely sure the point of having a thin terminal, when
> one also has PC's.

IIRC, the point was: zero configuration.
In contrast room full of PCs were a nightmare to maintain.

Stefan

On Monday, October 23, 2023 at 4:33:27 PM UTC-5, BGB wrote:
> On 10/23/2023 3:59 PM, Scott Lurndal wrote:
> > BGB <cr8...@gmail.com> writes:
> >> On 10/23/2023 2:52 PM, John Dallman wrote:
> >>> In article <uh6atm$39euq$1...@dont-email.me>, cr8...@gmail.com (BGB) wrote:
> >>>
> >>>> Looking stuff up, the "Sun Ray 150 Thin Client" looks most like the
> >>>> thing in my memory.
> >>>>
> >>>> Though, never saw it in use and never used it, was just sort of
> >>>> there...
> >>>
> >>> A guy from Sun came to my employer about that time to promote them to us.
> >>> We had no use for them, and it seems not many people did. The days of X
> >>> terminals were brief, and pre-dated the RISC revolution.
> >>>
> >>
> >> This was around 2003 or so IIRC.
> >>
> >> Granted, I am not entirely sure the point of having a thin terminal,
> >> when one also has PC's. Also never actually saw anyone using it for
> >> anything, was just sort of hanging out in one of my classes as a bit of
> >> a novelty.
> >
> > We used NCD X-terminals extensively from 1989 through 1997,
> > connected to Unix servers (mostly 88100-based MVME or Unisys
> > S/8400 systems).
> >
> > PCs were not viable alternatives in that era.
> >
> Yeah... But, if it were from the 1989..1997 timeframe, I don't expect it
> would have been using a full color LCD flat-panel display...
<
My 26" monitor I bought in '97 weighed at least 120 pounds and emitted
close to 600W of thermal energy into my office. Best color I every saw,
aside from emitting x-Rays and 600W it was rock solid.
>
> This was still fairly new tech at the time... and mostly limited to
> things like laptops.
>
> Granted, these sorts of LCD displays mostly replaced CRTs over the
> following years.
>
Panels still do not have the color gamut of the old "good" CRTs.
>
> Like, seemingly, someone, in around 2002 (apparently when this model
> went on the market), thought getting these terminals was a good idea.
>
> Or, if it was an older installation, I would have expected CRT based
> terminals.
>
>
> ...

On Monday, October 23, 2023 at 4:58:32 PM UTC-5, Stefan Monnier wrote:
> > Granted, I am not entirely sure the point of having a thin terminal, when
> > one also has PC's.
> IIRC, the point was: zero configuration.
> In contrast room full of PCs were a nightmare to maintain.
>
Not if you bought all of them with the same SKU and did not allow for
"upgrades" an had administrators install software.
>
> Stefan

On 10/23/2023 4:56 PM, Stefan Monnier wrote:
>> Granted, I am not entirely sure the point of having a thin terminal, when
>> one also has PC's.
>
> IIRC, the point was: zero configuration.
> In contrast room full of PCs were a nightmare to maintain.
>

OK. That makes sense.

Roughly a decade later, was taking some more classes.

The setup there was basically PCs, but with a sort of configuration
where the PC's didn't really remember anything on the local "C:" drive
(it only remembered files on a network drive with contents associated
with each student's login).

One could "install" programs by selecting them from a menu, but they
were associated with the user rather than on the PC being used. But,
logging in would sometimes take a rather long time...

Some of the students hacked around the menu-installer limitation by
having their "non-standard" programs (usually games and similar)
installed on their network drive.

IIRC, this was on Windows 7, not entirely sure how it was set up. I
think it was using PXE boot or similar though; and in cases where the
network boot went down, the PC's wouldn't boot and would get stuck in
the BIOS (and already booted PCs would fail to log in or would
unexpectedly lock up).

Though, IIRC the teacher PCs were independent of this system.

....

>> > Granted, I am not entirely sure the point of having a thin terminal, when
>> > one also has PC's.
>> IIRC, the point was: zero configuration.
>> In contrast room full of PCs were a nightmare to maintain.
> Not if you bought all of them with the same SKU and did not allow for
> "upgrades" an had administrators install software.

Hardware wasn't the problem: the problem was that it was still difficult
to keep users at bay (i.e. prevent them from messing up the system,
while at the same time give them enough rights to be able to get their
job done), and it was a constant struggle to keep them all uptodate.

Thin clients were supposed to have none of those downsides.

Nowadays, thin clients are everywhere, tho we call them "browsers"
instead :-)

Stefan

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, October 23, 2023 at 4:33:27=E2=80=AFPM UTC-5, BGB wrote:
>> On 10/23/2023 3:59 PM, Scott Lurndal wrote:=20
>> > BGB <cr8...@gmail.com> writes:=20
>> >> On 10/23/2023 2:52 PM, John Dallman wrote:=20
>> >>> In article <uh6atm$39euq$1...@dont-email.me>, cr8...@gmail.com (BGB) =
>wrote:=20
>> >>>=20
>> >>>> Looking stuff up, the "Sun Ray 150 Thin Client" looks most like the=
>=20
>> >>>> thing in my memory.=20
>> >>>>=20
>> >>>> Though, never saw it in use and never used it, was just sort of=20
>> >>>> there...=20
>> >>>=20
>> >>> A guy from Sun came to my employer about that time to promote them to=
> us.=20
>> >>> We had no use for them, and it seems not many people did. The days of=
> X=20
>> >>> terminals were brief, and pre-dated the RISC revolution.=20
>> >>>=20
>> >>=20
>> >> This was around 2003 or so IIRC.=20
>> >>=20
>> >> Granted, I am not entirely sure the point of having a thin terminal,=
>=20
>> >> when one also has PC's. Also never actually saw anyone using it for=20
>> >> anything, was just sort of hanging out in one of my classes as a bit o=
>f=20
>> >> a novelty.=20
>> >=20
>> > We used NCD X-terminals extensively from 1989 through 1997,=20
>> > connected to Unix servers (mostly 88100-based MVME or Unisys=20
>> > S/8400 systems).=20
>> >=20
>> > PCs were not viable alternatives in that era.=20
>> >
>> Yeah... But, if it were from the 1989..1997 timeframe, I don't expect it=
>=20
>> would have been using a full color LCD flat-panel display...=20

17" color and 16" b&W (NCD17c, NCD16).

><
>My 26" monitor I bought in '97 weighed at least 120 pounds and emitted
>close to 600W of thermal energy into my office. Best color I every saw,
>aside from emitting x-Rays and 600W it was rock solid.

I had one of the 26" Sony monitors when I was at SGI ('97-'00) (attached to
a 2p Octane). Heavy, but as you say, excellent color.

MitchAlsup <MitchAlsup@aol.com> writes:
>On Monday, October 23, 2023 at 4:58:32=E2=80=AFPM UTC-5, Stefan Monnier wro=
>te:
>> > Granted, I am not entirely sure the point of having a thin terminal, wh=
>en=20
>> > one also has PC's.
>> IIRC, the point was: zero configuration.=20
>> In contrast room full of PCs were a nightmare to maintain.=20
>>=20
>Not if you bought all of them with the same SKU and did not allow for
>"upgrades" an had administrators install software.

Even then.

The NCD's downloaded the software when booted.

scott@slp53.sl.home (Scott Lurndal) writes:
>We used NCD X-terminals extensively from 1989 through 1997,
>connected to Unix servers (mostly 88100-based MVME or Unisys
>S/8400 systems).

We have used NCD X-Terminals (19" B/W CRTs with 1280x1024 resolution)
since 1993. As someone wrote, a big advantage was ease of
administration. Another big advantage was that the X-Terminals
remained up-to-date for much longer than PCs of the day. We kept the
NCDs until 2002. During that time we went through a number of
servers, from DecStations with 16MB RAM or so over 21064 Alphas,
21164A Alphas, 21264B Alphas with 1GB RAM, Coppermines (Pentium III
750 and Celeron 800) and Palomino (Athlon MP). So our users always
used a relatively recent CPU while staying with the same X-Terminals.

We replaced the NCDs with Igel Thin Clients (the then-fashionable name
for X-Terminals) and LCD screens in 2002. We replaced the Igels with
Zotac Zbox nano CI540 Plus in 2014 or so that we also boot over the
network and use as X-Terminals with LTSP as software.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> We have used NCD X-Terminals (19" B/W CRTs with 1280x1024 resolution)
> since 1993. As someone wrote, a big advantage was ease of
> administration. Another big advantage was that the X-Terminals
> remained up-to-date for much longer than PCs of the day.

Another sweet spot for technology was the Linux Terminal Server Project.
Basically you'd PXE boot a thin client onto low spec diskless PC hardware,
with a server doing all the heavy lifting. It saved our local school
district thousands of dollars.

Software bloat being what it must be, eventually big apps like the browser
moved back on to the "thin" clients, who needed to be less thin. Eventually
all the win was lost, and that was the end of LTSP for us. It looks like it
has continued to evolve.

ChromeOS has filled the vacuum, in essence not that different from
the last iteration of LTSP we used.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

Scott Lurndal <scott@slp53.sl.home> schrieb:

> When the Sun-1 came out in the 80's, the bulk of
> technical computing was done on minicomputers (e.g. VAX)
> using graphical output devices like the 4014 and VK100 GIGI.

Without a numerical co-processor, the 68000 was not really
competetive for floating point. This probably let minicomputer
vendors sleep at night, for a time.

On 27.10.2023 15:01, Thomas Koenig wrote:
> Scott Lurndal <scott@slp53.sl.home> schrieb:
>
>> When the Sun-1 came out in the 80's, the bulk of
>> technical computing was done on minicomputers (e.g. VAX)
>> using graphical output devices like the 4014 and VK100 GIGI.
>
> Without a numerical co-processor, the 68000 was not really
> competetive for floating point. This probably let minicomputer
> vendors sleep at night, for a time.

There were the 68881 and 68882.
https://en.wikipedia.org/wiki/Motorola_68881

--
Bernd Linsel

On 27/10/2023 18:41, Bernd Linsel wrote:
> On 27.10.2023 15:01, Thomas Koenig wrote:
>> Scott Lurndal <scott@slp53.sl.home> schrieb:
>>
>>> When the Sun-1 came out in the  80's, the bulk of
>>> technical computing was done on minicomputers (e.g. VAX)
>>> using graphical output devices like the 4014 and VK100 GIGI.
>>
>> Without a numerical co-processor, the 68000 was not really
>> competetive for floating point.  This probably let minicomputer
>> vendors sleep at night, for a time.
>
> There were the 68881 and 68882.
> https://en.wikipedia.org/wiki/Motorola_68881

As I remember and they seem to state as well on this wikipedia page, the
68881/2 were designed for use with a 68020 (and later 68030) and not for
the 68000 itself.

I don't remember if it was at all possible to use a 68881 with a 68000.
But maybe by "68000" you meant the 68020 and later.

Bernd Linsel <bl1-thispartdoesnotbelonghere@gmx.com> schrieb:
> On 27.10.2023 15:01, Thomas Koenig wrote:
>> Scott Lurndal <scott@slp53.sl.home> schrieb:
>>
>>> When the Sun-1 came out in the 80's, the bulk of
>>> technical computing was done on minicomputers (e.g. VAX)
>>> using graphical output devices like the 4014 and VK100 GIGI.
>>
>> Without a numerical co-processor, the 68000 was not really
>> competetive for floating point. This probably let minicomputer
>> vendors sleep at night, for a time.
>
> There were the 68881 and 68882.
> https://en.wikipedia.org/wiki/Motorola_68881

Yes, but the Sun-1 was released in 1982 (without numeric
coprocessor), the 68881 only in 1984. The Sun-3 was the first
machine with a numeric coprocessor, which made serious
numeric work possible.