On 1/6/2024 8:04 PM, Dan Cross wrote:
> In article <uncrcr$q371$2@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/6/2024 4:22 PM, Single Stage to Orbit wrote:
>>> On Sat, 2024-01-06 at 02:33 +0000, Lawrence D'Oliveiro wrote:
>>>> On Fri, 5 Jan 2024 09:23:36 -0500, Arne Vajhøj wrote:
>>>>> Another example:
>>>>>
>>>>> SYS$SETPRV with PRV$M_SYSNAM  followed by SYS$CRELNM with
>>>>> LNM$_TABLE as
>>>>> "LNM$SYSTEM_TABLE".
>>>>>
>>>>> The API is not that complex. The semantics on VMS is well
>>>>> documented.
>>>>>
>>>>> But the code does not really make any sense on Linux. So what to
>>>>> do?
>>>>
>>>> We can emulate logical names on Linux beyond the per-process ones
>>>> with a server process and communication via some IPC mechanism. D-Bus
>>>> or Varlink might be good enough for this.
>>>
>>> if setenv() and getenv() were thread-safe it'd be easier to use these.
>>
>> I see environment variables being closer to VMS symbols than to
>> VMS logicals.
>>
>> But just closer not identical.
>
> Eh. Emulation of logical names would likely be done by
> maintaining and consulting symbol tables in the DCL "shell" (or
> whatever emulated DCL in this frankenstein "VMS on Linux"
> monstronsity) for user mode logicals and a symbol table
> maintained in a region of shared memory owned by some DSO-like
> shared object for the others.
>
> The idea of using some service that one communicates with via
> dbus to emulate logical names is absurd.

Direct access to shared memory would be more efficient
than an IPC to a process. But it also increases the risk
of data corruption. That is not a problem in VMS because
the data structures can not be trashed from user mode code,
but in the frankenstein "VMS on Linux" I don't know.

Note that mode and table are (mostly) independent.
Logicals can be user, supervisor, exec or kernel mode.
Logicals reside in process, job, group, system, cluster,
decwindows or a custom logical table.

Arne

In article <uncu14$q8b0$2@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 1/6/2024 8:04 PM, Dan Cross wrote:
>> In article <uncrcr$q371$2@dont-email.me>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 1/6/2024 4:22 PM, Single Stage to Orbit wrote:
>>>> On Sat, 2024-01-06 at 02:33 +0000, Lawrence D'Oliveiro wrote:
>>>>> On Fri, 5 Jan 2024 09:23:36 -0500, Arne Vajhøj wrote:
>>>>>> Another example:
>>>>>>
>>>>>> SYS$SETPRV with PRV$M_SYSNAM  followed by SYS$CRELNM with
>>>>>> LNM$_TABLE as
>>>>>> "LNM$SYSTEM_TABLE".
>>>>>>
>>>>>> The API is not that complex. The semantics on VMS is well
>>>>>> documented.
>>>>>>
>>>>>> But the code does not really make any sense on Linux. So what to
>>>>>> do?
>>>>>
>>>>> We can emulate logical names on Linux beyond the per-process ones
>>>>> with a server process and communication via some IPC mechanism. D-Bus
>>>>> or Varlink might be good enough for this.
>>>>
>>>> if setenv() and getenv() were thread-safe it'd be easier to use these.
>>>
>>> I see environment variables being closer to VMS symbols than to
>>> VMS logicals.
>>>
>>> But just closer not identical.
>>
>> Eh. Emulation of logical names would likely be done by
>> maintaining and consulting symbol tables in the DCL "shell" (or
>> whatever emulated DCL in this frankenstein "VMS on Linux"
>> monstronsity) for user mode logicals and a symbol table
>> maintained in a region of shared memory owned by some DSO-like
>> shared object for the others.
>>
>> The idea of using some service that one communicates with via
>> dbus to emulate logical names is absurd.
>
>Direct access to shared memory would be more efficient
>than an IPC to a process. But it also increases the risk
>of data corruption. That is not a problem in VMS because
>the data structures can not be trashed from user mode code,
>but in the frankenstein "VMS on Linux" I don't know.

This could actually be handled relatively straight-forwardly.
If the data were provided in the form of a DSO, then the kernel
could manage the mapping of this region so that it was
read-only; since the kernel is providing the data, it would
catch the page fault on a write, fetch the faulting operation
from the (user) program, and emulate it with appropriate
interlocks to avoid corruption. I don't know, but I imagine
VSI does already something similar in VMS on x86.

>Note that mode and table are (mostly) independent.
>Logicals can be user, supervisor, exec or kernel mode.
>Logicals reside in process, job, group, system, cluster,
>decwindows or a custom logical table.

Indeed. This whole nonsense about "VMS on Linux" makes the
extent of the problem even more glaring.

- Dan C.

On 1/6/2024 12:22 AM, Lawrence D'Oliveiro wrote:
> On Sat, 6 Jan 2024 00:10:26 -0500, Arne Vajhøj wrote:
>> Some like to blame MS for what happened. But the project execution does
>> not seem attractive to follow.
>
> It saved money over all. That was one of the main points of the exercise.

I am not sure a CIO would see it that way.

The official story is that it saved 11 million Euro.

That number came from a report provided to the city council 10 year
after project start, where they compared what they chose with
alternative strategies.

The bottom line was that the chosen Linux & OOo/LO strategy
had 11 million Euro lower cost than the Windows & MSO strategy.

Basically: MSO licenses 4.2 million, Windows licenses 2.6 million
and HW upgrades required by Windows 5 million compared to 0.3
million for Limux.

I am sure the numbers are correct. Or as close to as practically
possible.

But the assumption was that staff and end user training
cost was the same for doing the switch as for just upgrading
the MS solution.

And the software creation including the approx. 65000 lines
of code (mostly Java) for WollMux is set to zero.

Arne

On 1/6/2024 3:31 PM, Dan Cross wrote:
>
>
> Additionally, QNX runs nuclear power plants.

What, you say! QNX runs on the PDP-11? :-)

bill

On Sat, 6 Jan 2024 20:00:50 -0500, Arne Vajhøj wrote:

> On 1/6/2024 5:23 PM, Lawrence D'Oliveiro wrote:
>> On Sat, 6 Jan 2024 15:09:25 -0500, Arne Vajhøj wrote:
>>> On 1/5/2024 11:52 PM, Lawrence D'Oliveiro wrote:
>>>> So that’s the second page done. I could keep going on, but do you
>>>> want to shortcut the process by pointing out where you think the
>>>> traps lie?
>>>
>>> It becomes complex to maintain that process state in a VMS process
>>> style aka across image activations.
>>
>> Not sure how that’s relevant to the question about $GETJPI.
>
> GETJPI retrive that info, so that the info is correct per VMS semantics
> is important for GETJPI, and VMS semantics are a bit tricky because of
> the differences between VMS and *nix.

So which info do you think will cause trouble? If it wasn’t in the part of
the list I had already addressed, then point out which list items will
cause the trouble.

On Sat, 6 Jan 2024 20:31:08 -0500, Arne Vajhøj wrote:

> On 1/6/2024 12:22 AM, Lawrence D'Oliveiro wrote:
>
>> On Sat, 6 Jan 2024 00:10:26 -0500, Arne Vajhøj wrote:
>>
>>> Some like to blame MS for what happened. But the project execution
>>> does not seem attractive to follow.
>>
>> It saved money over all. That was one of the main points of the
>> exercise.
>
> The bottom line was that the chosen Linux & OOo/LO strategy had 11
> million Euro lower cost than the Windows & MSO strategy.

That is what “saving money” means, does it not.

> But the assumption was that staff and end user training cost was the
> same for doing the switch as for just upgrading the MS solution.

Given the major, disruptive changes that tend to happen between versions
of Microsoft’s software, that kind of thing sounds entirely reasonable.
Particularly since you have more control over UI changes on the Linux
side. They created their own “LiMux” distro, as I recall, as part of the
implementation.

> And the software creation including the approx. 65000 lines of code
> (mostly Java) for WollMux is set to zero.

Again, presumably just equivalent to similar software development that
would have had to be done on Windows anyway. And with inferior Windows
tools, to boot.

On 07/01/2024 01:25, Dan Cross wrote:
> In article <uncu14$q8b0$2@dont-email.me>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/6/2024 8:04 PM, Dan Cross wrote:
>>> In article <uncrcr$q371$2@dont-email.me>,
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> On 1/6/2024 4:22 PM, Single Stage to Orbit wrote:
>>>>> On Sat, 2024-01-06 at 02:33 +0000, Lawrence D'Oliveiro wrote:
>>>>>> On Fri, 5 Jan 2024 09:23:36 -0500, Arne Vajhøj wrote:
>>>>>>> Another example:
>>>>>>>
>>>>>>> SYS$SETPRV with PRV$M_SYSNAM  followed by SYS$CRELNM with
>>>>>>> LNM$_TABLE as
>>>>>>> "LNM$SYSTEM_TABLE".
>>>>>>>
>>>>>>> The API is not that complex. The semantics on VMS is well
>>>>>>> documented.
>>>>>>>
>>>>>>> But the code does not really make any sense on Linux. So what to
>>>>>>> do?
>>>>>>
>>>>>> We can emulate logical names on Linux beyond the per-process ones
>>>>>> with a server process and communication via some IPC mechanism. D-Bus
>>>>>> or Varlink might be good enough for this.
>>>>>
>>>>> if setenv() and getenv() were thread-safe it'd be easier to use these.
>>>>
>>>> I see environment variables being closer to VMS symbols than to
>>>> VMS logicals.
>>>>
>>>> But just closer not identical.
>>>
>>> Eh. Emulation of logical names would likely be done by
>>> maintaining and consulting symbol tables in the DCL "shell" (or
>>> whatever emulated DCL in this frankenstein "VMS on Linux"
>>> monstronsity) for user mode logicals and a symbol table
>>> maintained in a region of shared memory owned by some DSO-like
>>> shared object for the others.
>>>
>>> The idea of using some service that one communicates with via
>>> dbus to emulate logical names is absurd.
>>
>> Direct access to shared memory would be more efficient
>> than an IPC to a process. But it also increases the risk
>> of data corruption. That is not a problem in VMS because
>> the data structures can not be trashed from user mode code,
>> but in the frankenstein "VMS on Linux" I don't know.
>
> This could actually be handled relatively straight-forwardly.
> If the data were provided in the form of a DSO, then the kernel
> could manage the mapping of this region so that it was
> read-only; since the kernel is providing the data, it would
> catch the page fault on a write, fetch the faulting operation
> from the (user) program, and emulate it with appropriate
> interlocks to avoid corruption. I don't know, but I imagine
> VSI does already something similar in VMS on x86.
>
>> Note that mode and table are (mostly) independent.
>> Logicals can be user, supervisor, exec or kernel mode.
>> Logicals reside in process, job, group, system, cluster,
>> decwindows or a custom logical table.
>
> Indeed. This whole nonsense about "VMS on Linux" makes the
> extent of the problem even more glaring.
>
> - Dan C.
>

Even without VMS under linux, I have always wanted a dclsh. Remember
that wonderful, very limited PCDCL? I wrote scripts with that to do
things I couldn't do in a PC batch file. In a production environment.
Not that I need it now - I always write scripts in ksh, despite normally
using bash under linux

--
Chris

In article <und163$qmhu$2@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sat, 6 Jan 2024 20:31:08 -0500, Arne Vajhøj wrote:
>
>> On 1/6/2024 12:22 AM, Lawrence D'Oliveiro wrote:
>>
>>> On Sat, 6 Jan 2024 00:10:26 -0500, Arne Vajhøj wrote:
>>>
>>>> Some like to blame MS for what happened. But the project execution
>>>> does not seem attractive to follow.
>>>
>>> It saved money over all. That was one of the main points of the
>>> exercise.
>>
>> The bottom line was that the chosen Linux & OOo/LO strategy had 11
>> million Euro lower cost than the Windows & MSO strategy.
>
>That is what "saving money" means, does it not.

Not if your development and support costs are 4 times what you
save over a 10 year period. The development of WollMux itself
was probably around a million euros.

>> But the assumption was that staff and end user training cost was the
>> same for doing the switch as for just upgrading the MS solution.
>
>Given the major, disruptive changes that tend to happen between versions
>of Microsoft's software, that kind of thing sounds entirely reasonable.

Hogwosh. You seem to have no end of speculation and assumption,
but practically no data or evidence to back up your claims.

>Particularly since you have more control over UI changes on the Linux
>side. They created their own "LiMux" distro, as I recall, as part of the
>implementation.

Another added cost.

>> And the software creation including the approx. 65000 lines of code
>> (mostly Java) for WollMux is set to zero.
>
>Again, presumably just equivalent to similar software development that
>would have had to be done on Windows anyway. And with inferior Windows
>tools, to boot.

Apparently it was to recreate functionality that already existed
in Office.

- Dan C.

On Sun, 7 Jan 2024 02:59:17 +0000, Chris Townley wrote:

> Even without VMS under linux, I have always wanted a dclsh.

With that clunky PIPE command every time you want to feed the output of
one process into the input of another?

The whole command-line concept on VMS is fundamentally flawed. Notice that
on *nix, the command line is not a single string, it is an array of
strings. This makes it easy to pass special characters that might mean
something to the shell, simply by bypassing the shell.

And this is another case where Cutler seemed unable to learn from his
mistakes: he put the same brain damage into Windows NT.

On Sun, 7 Jan 2024 03:17:11 -0000 (UTC), Dan Cross wrote:

> The development of WollMux itself was probably around
> a million euros.

Speculation? Developing a whole entire Linux distro can actually be done
on a shoestring.

On 1/6/24 23:42, Dan Cross wrote:
> In article <uncc5u$ns66$2@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 6 Jan 2024 10:47:11 -0500, bill wrote:
>>
>>> On 1/5/2024 9:38 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> For what I mean by “workstation”, look at the capabilities of the Unix
>>>> workstations in the 1980s/1990s: remember, they ran the same OS as
>>>> their respective companies’ server offerings, with all the same
>>>> capabilities. It was Microsoft that came along and offered a
>>>> “Workstation” OS that had cut-
>>>> down capabilities compared to their “Server” offering, so they could
>>>> charge less for the former ... and more for the latter.
>>>
>>> Not sure I agree with this at all. It's been a long time and my memory
>>> may not be what it once was but I distinctly remember the only
>>> difference between NT Server and NT Workstation was Registry Settings.
>>
>> You are remembering NT 3.51, I think it was, when somebody discovered
>> that, indeed, all it took was a single Registry setting change to enable
>> “Server” functionality on an NT “Workstation” installation.
>>
>> Microsoft fixed that in the next version. Remember, it was not in their
>> interests to allow this sort of thing to continue, given the significant
>> difference in price between the two products.
>>
>> So you see, on the Unix side, the vendors never thought to charge any
>> different for the "workstation" versus "server" software, because it was
>> the exact same software, with the exact same capabilities.
>
> I remember pretty specifically maximum user limits on versions
> of commercial Unix. Most of the time it didn't matter for a
> workstation, where only one user at a time (generally) was
> logged into the machine. For servers and timesharing hosts?
> It was a big deal.
>
>> Today, the only OS in widespread use with this commonality of function
>> across disparate hardware configurations is Linux.
>
> Or FreeBSD. Or OpenBSD.
>
> - Dan C.
>

Been running FreeBSD for years now, Works out of the box on various
architectures and a base install takes around 20 minutes. Ditched
Linux as it became more bloated and especially, the systemd trainwreck,
which I saw as a power grab by RedGat. Gross amount of complexity added
for no good reason. Having said that, have Suse and xubuntu installed
on a couple of machines, for software compatability testing reasons.
Always liked Suse Linux in the past, but again systemd, the disease
that has infected so many Linux distros.

As for licensing, and having been around many vendor's unix offerings
for decades, the only onerous licensing was associated with third
party apps, where a license manager needed to be installed to run
the app. Embedded C cross compilers, real time os, and tools,for
example.

With Sun, the os came with the machine and you could do more or
less what you wanted to do with it. A full set of tools and basic C
compiler out of the box. If you had the hardware, the os revision
for that hardware release was perpetually licensed. Compared to a
greedy DEC, some still wonder why Sun became so successful...

Chris

On 1/7/24 00:19, Dan Cross wrote:
> In article <uncqas$pust$1@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 6 Jan 2024 23:42:26 -0000 (UTC), Dan Cross wrote:
>>
>>> I remember pretty specifically maximum user limits on versions of
>>> commercial Unix.
>>
>> How would such limits be enforced? Presumably they only applied to some
>> extra-cost "layered product", not to the core OS.
>
> No, they applied to the OS as a while.

Don't remember that at all. Not on SGI, Sun or HPUX, nor Ultrix, fwir.

Examples ?...

Chris

In article <une90c$1345e$1@dont-email.me>, chrisq <devzero@nospam.com> wrote:
>On 1/7/24 00:19, Dan Cross wrote:
>> In article <uncqas$pust$1@dont-email.me>,
>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>> On Sat, 6 Jan 2024 23:42:26 -0000 (UTC), Dan Cross wrote:
>>>
>>>> I remember pretty specifically maximum user limits on versions of
>>>> commercial Unix.
>>>
>>> How would such limits be enforced? Presumably they only applied to some
>>> extra-cost "layered product", not to the core OS.
>>
>> No, they applied to the OS as a while.
>
>Don't remember that at all. Not on SGI, Sun or HPUX, nor Ultrix, fwir.
>
>Examples ?...

SCO, IIRC. https://www.tech-insider.org/unix/research/1997/0407.html

- Dan C.

In article <une6iq$12vd9$1@dont-email.me>, chrisq <devzero@nospam.com> wrote:
>On 1/6/24 23:42, Dan Cross wrote:
>> [snip]
>> Or FreeBSD. Or OpenBSD.
>
>Been running FreeBSD for years now, Works out of the box on various
>architectures and a base install takes around 20 minutes. Ditched
>Linux as it became more bloated and especially, the systemd trainwreck,
>which I saw as a power grab by RedGat. Gross amount of complexity added
>for no good reason. Having said that, have Suse and xubuntu installed
>on a couple of machines, for software compatability testing reasons.
>Always liked Suse Linux in the past, but again systemd, the disease
>that has infected so many Linux distros.
>
>As for licensing, and having been around many vendor's unix offerings
>for decades, the only onerous licensing was associated with third
>party apps, where a license manager needed to be installed to run
>the app. Embedded C cross compilers, real time os, and tools,for
>example.

AIX licensing was a pain.

>With Sun, the os came with the machine and you could do more or
>less what you wanted to do with it. A full set of tools and basic C
>compiler out of the box. If you had the hardware, the os revision
>for that hardware release was perpetually licensed. Compared to a
>greedy DEC, some still wonder why Sun became so successful...

Ah SunOS. In so many ways, the Unix par excellence. It was sad
when they unbundled the C compiler and ditched the BSD kernel
with the switch to SVR4. SunPro was not cheap.

I remember seeing the writing on the wall when a friend of mine
was showing me a Pentium PC: "It's about half the speed of a
SPARCstation-5, but a quarter of the cost." Then they ditched
their core business to concentrate on Java standards. That's
when it was obvious Sun was going to fail: it was just a matter
of time.

- Dan C.

In article <undkh0$10jff$2@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sun, 7 Jan 2024 03:17:11 -0000 (UTC), Dan Cross wrote:
>> The development of WollMux itself was probably around
>> a million euros.
>
>Speculation? Developing a whole entire Linux distro can actually be done
>on a shoestring.

Supported over 10 years? Tell me you've never supported a
custom linux distro without telling me.

Your problem appears to be that you start a premise ("Linux is
better") and then cherry-pick "evidence" to try and prove that
you are right, ignoring anything that shows that you're wrong.

- Dan C.

On Sun, 2024-01-07 at 01:04 +0000, Dan Cross wrote:
> > I see environment variables being closer to VMS symbols than to
> > VMS logicals.
> >
> > But just closer not identical.
>
> Eh.  Emulation of logical names would likely be done by
> maintaining and consulting symbol tables in the DCL "shell" (or
> whatever emulated DCL in this frankenstein "VMS on Linux"
> monstronsity) for user mode logicals and a symbol table
> maintained in a region of shared memory owned by some DSO-like
> shared object for the others.
>
> The idea of using some service that one communicates with via
> dbus to emulate logical names is absurd.

I'd sqlite3 it. But I wouldn't. We have x64_86 VMS now.
--
Tactical Nuclear Kittens

On Sat, 2024-01-06 at 19:31 -0500, Arne Vajhøj wrote:
> > if setenv() and getenv() were thread-safe it'd be easier to use
> > these.
>
> I see environment variables being closer to VMS symbols than to
> VMS logicals.
>
> But just closer not identical.

Oh yes that's right, symbols and logicals are distinct, and logicals
can belong to different tables.
--
Tactical Nuclear Kittens

On Sun, 2024-01-07 at 02:59 +0000, Chris Townley wrote:
>
> Even without VMS under linux, I have always wanted a dclsh. Remember
> that wonderful, very limited PCDCL? I wrote scripts with that to do
> things I couldn't do in a PC batch file. In a production environment.
> Not that I need it now - I always write scripts in ksh, despite
> normally using bash under linux

I believe someone has tried to do that but my memory might be flawed.
--
Tactical Nuclear Kittens

On 1/7/24 14:04, Dan Cross wrote:
> In article <une6iq$12vd9$1@dont-email.me>, chrisq <devzero@nospam.com> wrote:
>> On 1/6/24 23:42, Dan Cross wrote:
>>> [snip]
>>> Or FreeBSD. Or OpenBSD.
>>
>> Been running FreeBSD for years now, Works out of the box on various
>> architectures and a base install takes around 20 minutes. Ditched
>> Linux as it became more bloated and especially, the systemd trainwreck,
>> which I saw as a power grab by RedGat. Gross amount of complexity added
>> for no good reason. Having said that, have Suse and xubuntu installed
>> on a couple of machines, for software compatability testing reasons.
>> Always liked Suse Linux in the past, but again systemd, the disease
>> that has infected so many Linux distros.
>>
>> As for licensing, and having been around many vendor's unix offerings
>> for decades, the only onerous licensing was associated with third
>> party apps, where a license manager needed to be installed to run
>> the app. Embedded C cross compilers, real time os, and tools,for
>> example.
>
> AIX licensing was a pain.

A single example :-). Have an RS6000 machine here, aix 6 from memory,
and was able to download a whole set of updates from the IBM site
without a single question about licensing. Filled in a form, then
got an email when the update set was ready. Seems some don't like
aix, but just another unix under the hood. The built in system
management and diagnostic tools are some of the best i've seen
anywhere. Probably expensive formally, but no worse than DEC in
the old days, or Sun since the Oracle takeover.

>
>> With Sun, the os came with the machine and you could do more or
>> less what you wanted to do with it. A full set of tools and basic C
>> compiler out of the box. If you had the hardware, the os revision
>> for that hardware release was perpetually licensed. Compared to a
>> greedy DEC, some still wonder why Sun became so successful...
>
> Ah SunOS. In so many ways, the Unix par excellence. It was sad
> when they unbundled the C compiler and ditched the BSD kernel
> with the switch to SVR4. SunPro was not cheap.
>

Yes, it was. Remember one company around 1990 that bought one of
the early Sun 3/60 workstations. Pushed the boat out for the full
colour 19" display, maxed out memory and storage, and we were
all blown away by the machine, capabilities and performance. It
was a few years later, doing comparisons between a uVax GPX, VMS
and a Sun 3/60, compiling Tex source and the Sun 3 was 4-5 times
faster.

Spent years working and programming DEC, but such hard work to get
anything done on VMS for s/w development, compared to the unix.
Everything an added cost, very little open source, when by then.
a whole raft of open source from ftp sites for Sun machines. Then
Sunsites all over the world helping to spread the word.
Different business model and target market I guess, but never
looked back to DEC since.

Only switched off the last Sparc box here around a year ago. No
problem with the system, but the cost of energy now makes it
totally uneconomic to run some of the older hardware 24x7.

> I remember seeing the writing on the wall when a friend of mine
> was showing me a Pentium PC: "It's about half the speed of a
> SPARCstation-5, but a quarter of the cost." Then they ditched
> their core business to concentrate on Java standards. That's
> when it was obvious Sun was going to fail: it was just a matter
> of time.
>

Perhaps Sun did lose their way a bit, but it was the early 90's
recession, the dot com boom crash, that caused the most damage.
Dozens of companies went bust and in some ways, that culture
of innovation and progress has never recovered since. It's been
an interesting journey though :-)...

Chris

> - Dan C.
>

On 1/7/24 13:57, Dan Cross wrote:
> In article <une90c$1345e$1@dont-email.me>, chrisq <devzero@nospam.com> wrote:
>> On 1/7/24 00:19, Dan Cross wrote:
>>> In article <uncqas$pust$1@dont-email.me>,
>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>> On Sat, 6 Jan 2024 23:42:26 -0000 (UTC), Dan Cross wrote:
>>>>
>>>>> I remember pretty specifically maximum user limits on versions of
>>>>> commercial Unix.
>>>>
>>>> How would such limits be enforced? Presumably they only applied to some
>>>> extra-cost "layered product", not to the core OS.
>>>
>>> No, they applied to the OS as a while.
>>
>> Don't remember that at all. Not on SGI, Sun or HPUX, nor Ultrix, fwir.
>>
>> Examples ?...
>
> SCO, IIRC. https://www.tech-insider.org/unix/research/1997/0407.html
>

Lol. I would not touch anything SCO. Fwir, they exist purely to
litigate against others :-)...

> - Dan C.
>

On 07.01.2024 15:04, Dan Cross wrote:

>
> AIX licensing was a pain.
>

AIX base OS doesn't need license keys or PAKs or such.
Third party software might, but that's not AIX specific.

On 1/7/2024 10:29 AM, chrisq wrote:
> On 1/7/24 14:04, Dan Cross wrote:
>> I remember seeing the writing on the wall when a friend of mine
>> was showing me a Pentium PC: "It's about half the speed of a
>> SPARCstation-5, but a quarter of the cost."  Then they ditched
>> their core business to concentrate on Java standards.  That's
>> when it was obvious Sun was going to fail: it was just a matter
>> of time.
>>
>
> Perhaps Sun did lose their way a bit, but it was the early 90's
> recession, the dot com boom crash, that caused the most damage.
> Dozens of companies went bust and in some ways, that culture
> of innovation and progress has never recovered since. It's been
> an interesting journey though :-)...

Sun had a problem:
- Solaris/SPARC servers were more expensive than Linux/x86-64 servers
- the applications running on Solaris/SPARC was typical not that
difficult to port to Linux

Asking for a premium without sufficient vendor lock-in is a bad
business case.

Arne

On Sun, 2024-01-07 at 14:05 +0000, Dan Cross wrote:
> > Speculation? Developing a whole entire Linux distro can actually be
> > done on a shoestring.
>
> Supported over 10 years?  Tell me you've never supported a
> custom linux distro without telling me.

Haha :-D

Slackware since 1997 and then Gentoo after 2002. Fab times. One of the
oldest files on my system that's come with me when I moved to newer
machines is the emerge log and that was started in 2005.

I've gone through 32bit x86, 32bit SPARC, 32bit PPC, 64bit SPARC, 64bit
x86 over the years. Hopefully Gentoo will still with me when I boldly
go where no man has ever returned from.
--
Tactical Nuclear Kittens

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>The whole command-line concept on VMS is fundamentally flawed. Notice that
>on *nix, the command line is not a single string, it is an array of
>strings. This makes it easy to pass special characters that might mean
>something to the shell, simply by bypassing the shell.

Having made the Unix-to-VMS transition in the late eighties, the two things
I really liked about DCL were the handling of wildcards and the ability to
use [....] for recursive file paths. I would love to have those two things
in bash.

>And this is another case where Cutler seemed unable to learn from his
>mistakes: he put the same brain damage into Windows NT.

Having individual disks being treated as their own heirarchy referenced to
the disk itself rather than mounted somewhere else in some other filesystem
also seemed like a big step backwards for NT, yes. It made sense in RT-11
but by the time VMS came along let alone Win NT, the Unix-style
single-heirarchy system was clearly more flexible.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

In article <unegfi$1497f$2@dont-email.me>, chrisq <devzero@nospam.com> wrote:
>On 1/7/24 13:57, Dan Cross wrote:
>>>
>>> Don't remember that at all. Not on SGI, Sun or HPUX, nor Ultrix, fwir.
>>>
>>> Examples ?...
>>
>> SCO, IIRC. https://www.tech-insider.org/unix/research/1997/0407.html
>
>Lol. I would not touch anything SCO. Fwir, they exist purely to
>litigate against others :-)...

This was not initially the case. SCO was once an engineering-driven company
that was considered a seriously good place for programmers to work. They
had a huge programming and design staff, a hot tub available for technical
staff, and some highly respectable products.

By 1997 this had started to change and SCO was starting to get taken over
by lawyers. Within a few years there was nothing left but lawyers and they
had turned into a patent holding company.

But this was not originally the case and they are sorely missed.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."