On Fri, 14 Jul 2023 11:17:26 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>Muttley@dastardlyhq.com wrote:
>> Unfortunately a lot of tech companies have great
>> engineers but bad management. See Sun Microsystems
>> for further examples.
>
>Yes, I remember very well when Oracle acquired Sun. Some
>notable UNIX innovations are Sun's achievements.
>Everybody knows NFS and ZFS.
>
>We used to have some SPARC Solaris servers, but in the
>end Red Hat Enterprise Linux won. I suppose Solaris
>is still being developed by Oracle, but some people
>have said it is now much slower than Linux.

Last proper Solaris update was 5 years ago and that was 11.4. Version 11.0 was
released in 2011 so I think its fair to say its just legacy support now.

Muttley@dastardlyhq.com wrote:
> Last proper Solaris update was 5 years ago and
> that was 11.4. Version 11.0 was released in 2011
> so I think its fair to say its just legacy support now.

I googled "solaris roadmap" and one of the hits was
this Oracle blog:

https://blogs.oracle.com/solaris/post/long-live-solaris-11-until-at-least-2034-to-be-exact

Its topic says:

"Long live Solaris 11! - Until at least 2034 to be exact".

So if you are willing to pay for "Extended Support", whatever
that means, your Solaris has over ten years left. In a fast
moving IT world, it is a long time.

You must be right about the fact that no major Solaris OS
updates will be available.

br,
KK

On Fri, 14 Jul 2023 11:41:48 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>Muttley@dastardlyhq.com wrote:
>> Last proper Solaris update was 5 years ago and
>> that was 11.4. Version 11.0 was released in 2011
>> so I think its fair to say its just legacy support now.
>
>I googled "solaris roadmap" and one of the hits was
>this Oracle blog:
>
>
>https://blogs.oracle.com/solaris/post/long-live-solaris-11-until-at-least-2034-
>to-be-exact
>
>Its topic says:
>
> "Long live Solaris 11! - Until at least 2034 to be exact".

IOW you have 11 years to switch to another OS.

>So if you are willing to pay for "Extended Support", whatever
>that means, your Solaris has over ten years left. In a fast
>moving IT world, it is a long time.

Indeed. I can't imagine it'll get any significant updates in that time, just
bug fixes.

Muttley@dastardlyhq.com wrote:
> IOW you have 11 years to switch to another OS.

You probably remember that for a brief period of
time, Solaris kernel was open source. Its license
was something called CDDL.

The open source status did not last for long
and Oracle reverted back to its original
closed source policy. But they could not take
back what had already been released as OpenSolaris.

Solaris lovers have created their own Unix OS
based on the OpenSolaris kernel:

https://en.wikipedia.org/wiki/OpenIndiana

According to that Wikipedia page, the project
OpenIndiana is active and their latest release
was on April 21, 2023.

Then there is OmniOS that is also based on
OpenSolaris. Their homepage is:

https://omnios.org/

As of this writing, the project is alive:

"On the 1st of May 2023, the OmniOSce Association has
released a new stable version of OmniOS - The Open
Source Enterprise Server OS. The release comes with
many tool updates, brand-new features and additional
hardware support"

They claim that OmniOS is particularly well-suited
for serving as a virtualization host. Some people
are suspicious of Linux kernel development's quick
pace and they prefer to use an OS that is more
immutable, if you can call it that.

I got no experience with OpenIndiana or OmniOS.
I have only booted OmniOS once or twice to take a
quick look.

br,
KK

On Fri, 14 Jul 2023 16:04:03 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>Muttley@dastardlyhq.com wrote:
>> IOW you have 11 years to switch to another OS.
>
>You probably remember that for a brief period of
>time, Solaris kernel was open source. Its license
>was something called CDDL.
>
>The open source status did not last for long
>and Oracle reverted back to its original
>closed source policy. But they could not take
>back what had already been released as OpenSolaris.

I got a CD of opensolaris back in the day. Looked nice but almost none
of the hardware on my laptop worked including sound so it was fairly pointless.
Maybe as a server OS it was good.

>I got no experience with OpenIndiana or OmniOS.
>I have only booted OmniOS once or twice to take a
>quick look.

No doubt fun for the devs but no sane person would use them as a daily OS.

Muttley@dastardlyhq.com wrote:
> I got a CD of opensolaris back in the day. Looked nice but almost none
> of the hardware on my laptop worked including sound so it was fairly pointless.

The OpenSolaris project never really took off big time.
Most people capable of doing Unix kernel development wanted
to contribute to Linux, FreeBSD, OpenBSD, NetBSD, etc.
Thus it is not surprising that your laptop did not
work properly. No drivers, no fun.

> Maybe as a server OS it was good.

If you think about stability, Solaris was rock solid
like UNIX in general tends to be. I never saw any crashes
or serious malfunctioning.

Running commercial Sun Solaris on Sun SPARC hardware
had the benefit that you knew that *if* something
were to go wrong, you could just report the problem to
Sun Microsystems. They shipped both the hardware and
the software and they would accept responsibility
for finding a fix.

Running Linux on some random Intel hardware, you
could report a problem to those who sold the hardware,
and they would say that their hardware is fine, the
fault must be in Linux kernel. I know this has happened.

When it comes to performance, at one point in distant
time some benchmarks suggested that Solaris was 10%
slower than Linux, but who knows what they even
measured. I have recently heard that Solaris is
now noticeably slower than Linux.

There was also a time when Solaris performed better
on desktop than Linux. A colleague once showed me
how. He started a heavily I/O-bound process on
Linux, perhaps untarring a 2GB file or something
like that. Interactive use became hopeless right
away and the GUI was very unresponsive indeed.

Next he started the same process on Solaris.
The GUI worked quite flawlessly with no signs
of being stuck.

>>I got no experience with OpenIndiana or OmniOS.
>>I have only booted OmniOS once or twice to take a
>>quick look.
>
> No doubt fun for the devs but no sane person would use them as a daily OS.

If by "daily OS" you mean your desktop use, then I
suppose you are right.

It is extremely important the virtualization hosts
are super stable. I am guessing that OmniOS probably
is. It would be interesting to hear real experiences.

br,
KK

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>Muttley@dastardlyhq.com wrote:
>> I got a CD of opensolaris back in the day. Looked nice but almost none
>> of the hardware on my laptop worked including sound so it was fairly pointless.
>
>The OpenSolaris project never really took off big time.
>Most people capable of doing Unix kernel development wanted
>to contribute to Linux, FreeBSD, OpenBSD, NetBSD, etc.
>Thus it is not surprising that your laptop did not
>work properly. No drivers, no fun.
>
>> Maybe as a server OS it was good.
>
>If you think about stability, Solaris was rock solid
>like UNIX in general tends to be. I never saw any crashes
>or serious malfunctioning.
>
>Running commercial Sun Solaris on Sun SPARC hardware
>had the benefit that you knew that *if* something
>were to go wrong, you could just report the problem to
>Sun Microsystems. They shipped both the hardware and
>the software and they would accept responsibility
>for finding a fix.
>
>Running Linux on some random Intel hardware, you
>could report a problem to

redhat or suse who would be happy to fix it for you.

Scott Lurndal <scott@slp53.sl.home> wrote:
> redhat or suse who would be happy to fix it for you.

The incident I was referring to occurred long
time ago in 1999 or 2000. The NFS file
server was running Red Hat Linux 6.0 or
something like that. Red Hat Enterprise Linux
did not exist back then. I don't know about
SUSE.

I don't know whether commercial support from
Red Hat was even available during those times, but
the server in question was bought and installed by
the previous system adminstrator who had left the
building for good.

The hardware RAID5 box and the server i686 box
had support contracts. The Red Hat Linux
OS did not.

One day one of the disks in the RAID5 failed.
Since we had a support contract, we reported
the issue and a guy appeared with a replacement
disk. The old disk out, the new disk in, so
far so good.

But not all was great, as the filesystem kept
getting corrupted. We fixed it with fsck time
after time, but the problem kept occurring
particularly during the nights when the tape
backups caused lots of I/O.

The hardware vendor blamed the Linux kernel
and claimed that their RAID5 and the new
disk were functioning 100% properly.

After several days, I guess it was me who
finally figured out that the new SCSI disk
had one jumper that was set in an incorrect
position. The service guy had made a costly
mistake.

I cannot recall the exact details, but I
guess it was a matter of choosing between
some kind Direct IO and Cached IO. I also
cannot recall which setting was the right
one, but once the jumper was set correctly,
filesystem no longer got corrupted.

After that we replaced the Linux file server
with Sun SPARC hardware running Solaris.

br,
KK

On 7/14/2023 4:17 AM, Kalevi Kolttonen wrote:
> Muttley@dastardlyhq.com wrote:
>> Interesting. Never heard of it but given they'd already had a high powered 16
>> bit machine in the Amiga for 5 years it seems utterly pointless and I can see
>> why it was canned.
>
> Exactly. Commodore's shaky business moves also included
> this weird device:
>
> https://en.wikipedia.org/wiki/Commodore_CDTV
>
> I guess it is basically Amiga hardware that is supposed
> to be a gaming console. Again, some Commodore collectors
> want to buy them, but I don't think CDTV was at all
> successful when it was released.
>
>> Unfortunately a lot of tech companies have great
>> engineers but bad management. See Sun Microsystems
>> for further examples.
>
> Yes, I remember very well when Oracle acquired Sun. Some
> notable UNIX innovations are Sun's achievements.
> Everybody knows NFS and ZFS.

Fwiw, I won a brand new sunfire t2000 with my entry into Sun's
coolthreads project. Right after that, iirc, Oracle acquired Sun.

>
> We used to have some SPARC Solaris servers, but in the
> end Red Hat Enterprise Linux won. I suppose Solaris
> is still being developed by Oracle, but some people
> have said it is now much slower than Linux.

kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:
>> redhat or suse who would be happy to fix it for you.
>
>The incident I was referring to occurred long
>time ago in 1999 or 2000. The NFS file
>server was running Red Hat Linux 6.0 or
>something like that. Red Hat Enterprise Linux
>did not exist back then. I don't know about
>SUSE.
>
>I don't know whether commercial support from
>Red Hat was even available during those times, but
>the server in question was bought and installed by
>the previous system adminstrator who had left the
>building for good.
>
>The hardware RAID5 box and the server i686 box
>had support contracts. The Red Hat Linux
>OS did not.
>
>One day one of the disks in the RAID5 failed.
>Since we had a support contract, we reported
>the issue and a guy appeared with a replacement
>disk. The old disk out, the new disk in, so
>far so good.
>
>But not all was great, as the filesystem kept
>getting corrupted. We fixed it with fsck time
>after time, but the problem kept occurring
>particularly during the nights when the tape
>backups caused lots of I/O.
>
>The hardware vendor blamed the Linux kernel
>and claimed that their RAID5 and the new
>disk were functioning 100% properly.
>
>After several days, I guess it was me who
>finally figured out that the new SCSI disk
>had one jumper that was set in an incorrect
>position. The service guy had made a costly
>mistake.

So it wasn't a redhat or kernel problem after all;
so a software service contract wouldn't have been
useful to you.

In any case, Redhat offered paid support for Redhat 6
(I ran RH6 for several years up to the mid-aughts
on a web/mail server). From my old logs:

$ date
Mon May 10 11:27:56 PDT 2006
$ uptime
11:28am up 1528 days, 6:47, 8 users, load average: 0.23, 0.12, 0.05

Scott Lurndal <scott@slp53.sl.home> wrote:
> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>>Scott Lurndal <scott@slp53.sl.home> wrote:
> So it wasn't a redhat or kernel problem after all;
> so a software service contract wouldn't have been
> useful to you.

You are correct about that. But our main goal
when favouring Sun Microsystems and Sun Solaris
was that in case of mysterious problems starting
to occur, we won't have to deal with *two different
companies*.

In other words, if both the hardware platform
and OS come from a single source, then you know
who to contact as there is only one option.

If you have two companies involved, then it is more
troublesome possibly having to contact both of them.

In a bad case they could even blame each other, not
accepting the responsibility to solve the problem.
It would be rare, but could sometimes happen.

> In any case, Redhat offered paid support for Redhat 6
> (I ran RH6 for several years up to the mid-aughts
> on a web/mail server). From my old logs:
>
> $ date
> Mon May 10 11:27:56 PDT 2006
> $ uptime
> 11:28am up 1528 days, 6:47, 8 users, load average: 0.23, 0.12, 0.05

Okay, thanks for the information.

br,
KK

Kalevi Kolttonen <kalevi@kolttonen.fi> wrote:
> Scott Lurndal <scott@slp53.sl.home> wrote:
>> kalevi@kolttonen.fi (Kalevi Kolttonen) writes:
>>>Scott Lurndal <scott@slp53.sl.home> wrote:
>> So it wasn't a redhat or kernel problem after all;
>> so a software service contract wouldn't have been
>> useful to you.
> In other words, if both the hardware platform
> and OS come from a single source, then you know
> who to contact as there is only one option.
>
> If you have two companies involved, then it is more
> troublesome possibly having to contact both of them.
>
> In a bad case they could even blame each other, not
> accepting the responsibility to solve the problem.
> It would be rare, but could sometimes happen.

I would like to add one more recent example. My Lenovo
laptop runs Fedora Linux. I bought it from a big store
here in Finland, but for politeness reasons, I won't
mention its name.

The laptop somehow "died" not long after I had bought
it. The screen just went completely blank and after
that nothing worked, the laptop was dead as a brick.

I took the laptop to the big store where they said
that they only care about Lenovos that have Windows
installed. Fedora Linux is not supported and installing
it has voided the warranty.

I argued that these Lenovos come preinstalled with
Fedora Linux in some areas of the world. I kept
insisting that the warranty must valid, and they
accepted the laptop to be serviced.

After exactly two weeks, the laptop arrived from
Germany to Finland. The service guys had inspected
the machine and concluded that there was nothing
wrong about it.

When I fetched it from the big store and I tried
it at home, it worked flawlessly. I have no
clue about what happened.

Well, that story was probably too long and boring,
but should illustrate that some companies can
blame Linux even now when it is pretty obvious that
it has to be a hardware related issue.

br,
KK

On Fri, 14 Jul 2023 16:56:37 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>If you think about stability, Solaris was rock solid
>like UNIX in general tends to be. I never saw any crashes
>or serious malfunctioning.

True. Ditto AIX. HP-UX not so much IME.

>When it comes to performance, at one point in distant
>time some benchmarks suggested that Solaris was 10%
>slower than Linux, but who knows what they even
>measured. I have recently heard that Solaris is
>now noticeably slower than Linux.

Too many variables to know what the cause might be.
Were they tested on the same hardware?
Were the kernels compiled by different compilers?
What sort of schedulers were used?
Was I/O prioritised over CPU or vice verca?

etc etc.

>There was also a time when Solaris performed better
>on desktop than Linux. A colleague once showed me
>how. He started a heavily I/O-bound process on
>Linux, perhaps untarring a 2GB file or something
>like that. Interactive use became hopeless right
>away and the GUI was very unresponsive indeed.

You can tune the linux kernel to balance I/O vs CPU now.

>> No doubt fun for the devs but no sane person would use them as a daily OS.
>
>If by "daily OS" you mean your desktop use, then I
>suppose you are right.

I was thinking more of the fact that they're probably little more than
hobby OS's with very few people working on them who one day will get bored
and move on. There'll be little general support, little hardware support and any
wierd bugs will take an age to get sorted if at all.

>It is extremely important the virtualization hosts
>are super stable. I am guessing that OmniOS probably
>is. It would be interesting to hear real experiences.

Hmm, maybe.

Muttley@dastardlyhq.com wrote:
> On Fri, 14 Jul 2023 16:56:37 -0000 (UTC)
> kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>>If you think about stability, Solaris was rock solid
>>like UNIX in general tends to be. I never saw any crashes
>>or serious malfunctioning.
>
> True. Ditto AIX. HP-UX not so much IME.

We used to have only one HP-UX machine, so not
much experience with this OS. In our use, it never
crashed or did anything crazy.

>>When it comes to performance, at one point in distant
>>time some benchmarks suggested that Solaris was 10%
>>slower than Linux, but who knows what they even
>>measured. I have recently heard that Solaris is
>>now noticeably slower than Linux.
>
> Too many variables to know what the cause might be.
> Were they tested on the same hardware?
> Were the kernels compiled by different compilers?
> What sort of schedulers were used?
> Was I/O prioritised over CPU or vice verca?
>
> etc etc.

Quite true. Their observation was pretty useless
and hard to generalize.

>>There was also a time when Solaris performed better
>>on desktop than Linux. A colleague once showed me
>>how. He started a heavily I/O-bound process on
>>Linux, perhaps untarring a 2GB file or something
>>like that. Interactive use became hopeless right
>>away and the GUI was very unresponsive indeed.
>
> You can tune the linux kernel to balance I/O vs CPU now.
>
>>> No doubt fun for the devs but no sane person would use them as a daily OS.
>>
>>If by "daily OS" you mean your desktop use, then I
>>suppose you are right.
>
> I was thinking more of the fact that they're probably little more than
> hobby OS's with very few people working on them who one day will get bored
> and move on. There'll be little general support, little hardware support and any
> wierd bugs will take an age to get sorted if at all.

Compared to major operating systems, OpenIndiana
and OmniOS must be very unpopular, but according
to the OmniOS webpage, at least they offer some
kind of commercial support.

It is indeed hard to believe that their user base
is that large.

br,
KK

On Sat, 15 Jul 2023 09:10:34 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>Muttley@dastardlyhq.com wrote:
>> On Fri, 14 Jul 2023 16:56:37 -0000 (UTC)
>> kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>>>If you think about stability, Solaris was rock solid
>>>like UNIX in general tends to be. I never saw any crashes
>>>or serious malfunctioning.
>>
>> True. Ditto AIX. HP-UX not so much IME.
>
>We used to have only one HP-UX machine, so not
>much experience with this OS. In our use, it never
>crashed or did anything crazy.

The main *nix at my uni was HP-UX and under heavy load when dozens or more
students were using it at the same time it often collapsed in a heap and had to
be rebooted. Also at the time (I'm sure they fixed it at some point) in the
early 90s it was vulnerable to fork bombs. They'd crash it instantly.

Muttley@dastardlyhq.com wrote:
> The main *nix at my uni was HP-UX and under heavy load when dozens or more
> students were using it at the same time it often collapsed in a heap and had to
> be rebooted. Also at the time (I'm sure they fixed it at some point) in the
> early 90s it was vulnerable to fork bombs. They'd crash it instantly.

Sounds awful. My experience is from ten years later
than that. I am not sure but that HP-UX was probably
PA-RISC of some kind.

br,
KK

On Sat, 15 Jul 2023 09:23:45 -0000 (UTC)
kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>Muttley@dastardlyhq.com wrote:
>> The main *nix at my uni was HP-UX and under heavy load when dozens or more
>> students were using it at the same time it often collapsed in a heap and had
>to
>> be rebooted. Also at the time (I'm sure they fixed it at some point) in the
>> early 90s it was vulnerable to fork bombs. They'd crash it instantly.
>
>Sounds awful. My experience is from ten years later
>than that. I am not sure but that HP-UX was probably
>PA-RISC of some kind.

HP9000 machines whatever CPU they had.

On 15/07/2023 01:14, Kalevi Kolttonen wrote:
>
> After exactly two weeks, the laptop arrived from
> Germany to Finland. The service guys had inspected
> the machine and concluded that there was nothing
> wrong about it.
>
> When I fetched it from the big store and I tried
> it at home, it worked flawlessly. I have no
> clue about what happened.
>
> Well, that story was probably too long and boring,
> but should illustrate that some companies can
> blame Linux even now when it is pretty obvious that
> it has to be a hardware related issue.
>

Most people in computer stores are clueless. They have very little idea
of what they are selling, and get scared when there is something
unfamiliar to them. Their job is to persuade customers to pay for
extras - extra hardware like cables or bags, extra insurance or extended
warranties, or extra software like antivirus stuff. Shops make very
little markup on the computers, and rely on the extras to make a profit.
And supporting anything slightly unusual would mean paying for staff
training.

So they will always try to say things are outside warranty, and always
try to refuse help if you've done something outside their tiny area of
"reboot, apply updates, try safe mode" knowledge.

As for how your laptop worked after its "service", there are many
possibilities. Sometimes hardware just needs a good power-cycle reset -
you don't get that with a reset button. Taking out the battery can
help, if it is removable, otherwise a hung/crashed laptop sitting for a
week in the post will run down the battery enough for a restart. There
could also be something physical, such as poor contacts inside, and
shaking the laptop enough made it work again.

On Sat, 15 Jul 2023 13:32:35 +0200
David Brown <david.brown@hesbynett.no> wrote:
>Most people in computer stores are clueless. They have very little idea
>of what they are selling, and get scared when there is something
>unfamiliar to them. Their job is to persuade customers to pay for

The "Geniuses" title for the caffeine overdosed failed actors in Apple stores
always makes me smile. When my wife took her malfunctioning iPad down to one
recently to get it fixed she asked what was wrong with it after he'd checked it
out. His answer (and this is true, I'm not exaggerting): "Its broken madam".

Truly a savant.

The repair consisted of giving her a new one which you might thing is great
but she lost all the pictures and videos on hers that weren't backed up.

Muttley@dastardlyhq.com writes:
>On Fri, 14 Jul 2023 16:56:37 -0000 (UTC)
>kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>>If you think about stability, Solaris was rock solid
>>like UNIX in general tends to be. I never saw any crashes
>>or serious malfunctioning.
>
>True. Ditto AIX. HP-UX not so much IME.
>
>>When it comes to performance, at one point in distant
>>time some benchmarks suggested that Solaris was 10%
>>slower than Linux, but who knows what they even
>>measured. I have recently heard that Solaris is
>>now noticeably slower than Linux.
>
>Too many variables to know what the cause might be.
>Were they tested on the same hardware?
>Were the kernels compiled by different compilers?
>What sort of schedulers were used?
>Was I/O prioritised over CPU or vice verca?
>
>etc etc.
>
>>There was also a time when Solaris performed better
>>on desktop than Linux. A colleague once showed me
>>how. He started a heavily I/O-bound process on
>>Linux, perhaps untarring a 2GB file or something
>>like that. Interactive use became hopeless right
>>away and the GUI was very unresponsive indeed.
>
>You can tune the linux kernel to balance I/O vs CPU now.

In those days, the Solaris box had a high-end
SCSI disk drive. The Linux box might have had
an PIO IDE drive.

On 15/07/2023 16:59, Muttley@dastardlyhq.com wrote:
> On Sat, 15 Jul 2023 13:32:35 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> Most people in computer stores are clueless. They have very little idea
>> of what they are selling, and get scared when there is something
>> unfamiliar to them. Their job is to persuade customers to pay for
>
> The "Geniuses" title for the caffeine overdosed failed actors in Apple stores
> always makes me smile. When my wife took her malfunctioning iPad down to one
> recently to get it fixed she asked what was wrong with it after he'd checked it
> out. His answer (and this is true, I'm not exaggerting): "Its broken madam".
>
> Truly a savant.
>
> The repair consisted of giving her a new one which you might thing is great
> but she lost all the pictures and videos on hers that weren't backed up.
>

My son was once in an argument with a salesguy in a computer shop while
looking for a new laptop. He didn't need a very powerful one, but
wanted more RAM than the cheap ones had - and was therefore wanted one
where he could easily upgrade the RAM. The sales guy kept telling him
he didn't need more RAM, and said "I've been selling laptops for nearly
a decade - you'd think I'd know more than the customer!" My son
replied, "Yes, you'd think that" - and left the shop.

I often find the smaller places are much better. They are typically
staffed by people who are interested in what they are doing - and also
more interested in the customer, unlike big shops.

On 7/15/2023 7:59 AM, Muttley@dastardlyhq.com wrote:
> On Sat, 15 Jul 2023 13:32:35 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> Most people in computer stores are clueless. They have very little idea
>> of what they are selling, and get scared when there is something
>> unfamiliar to them. Their job is to persuade customers to pay for
>
> The "Geniuses" title for the caffeine overdosed failed actors in Apple stores
> always makes me smile. When my wife took her malfunctioning iPad down to one
> recently to get it fixed she asked what was wrong with it after he'd checked it
> out. His answer (and this is true, I'm not exaggerting): "Its broken madam".
>
> Truly a savant.
>
> The repair consisted of giving her a new one which you might thing is great
> but she lost all the pictures and videos on hers that weren't backed up.
>

The "Geniuses":

https://youtu.be/rgtNuOpE0uA

Watch out if they start doing this shit:

https://youtu.be/rgtNuOpE0uA?t=41

;^)

On 7/15/2023 2:17 AM, Muttley@dastardlyhq.com wrote:
> On Sat, 15 Jul 2023 09:10:34 -0000 (UTC)
> kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>> Muttley@dastardlyhq.com wrote:
>>> On Fri, 14 Jul 2023 16:56:37 -0000 (UTC)
>>> kalevi@kolttonen.fi (Kalevi Kolttonen) wrote:
>>>> If you think about stability, Solaris was rock solid
>>>> like UNIX in general tends to be. I never saw any crashes
>>>> or serious malfunctioning.
>>>
>>> True. Ditto AIX. HP-UX not so much IME.
>>
>> We used to have only one HP-UX machine, so not
>> much experience with this OS. In our use, it never
>> crashed or did anything crazy.
>
> The main *nix at my uni was HP-UX and under heavy load when dozens or more
> students were using it at the same time it often collapsed in a heap and had to
> be rebooted. Also at the time (I'm sure they fixed it at some point) in the
> early 90s it was vulnerable to fork bombs. They'd crash it instantly.
>
>

In the early 80s, we had VAX-780s at UCSC, running 4.2BSD
(not Open/Net/FreeBSD, just straight from Berkeley BSD).

At the end of the semester one year, we got one of them up to a load
average in the 70s. The thing slowed to a crawl, but... IT. DID. NOT.
CRASH. Period. Rock solid.

On 7/9/2023 8:37 AM, Scott Lurndal wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>> On 7/9/2023 3:43 AM, David Brown wrote:
>>> On 08/07/2023 20:28, Muttley@dastardlyhq.com wrote:
>>>> On Sat, 8 Jul 2023 18:01:12 +0200
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> Am 08.07.2023 um 16:59 schrieb Muttley@dastardlyhq.com:
>>>>>> How do you think online multiplayer RPGs work?
>>>>>
>>>>> The only transfer a small amout of state about the player over the
>>>>
>>>> There's also a large amount of state about everything else going on
>>>> in the simulated world that has to be uploaded to each player which
>>>> has to be
>>>> kept in sync.
>>>>
>>>
>>> Yes, that would be another type of application where the server would
>>> need very fast network card(s).  It's a different case from Scott's,
>>> since online games generally aim for smaller amounts of data at a time
>>> but handle vast numbers of connections (hundreds of thousands, or more)
>>> and also want lower latencies.  For Scott's file servers, there are only
>>> hundreds of client machines, but the data files are very large and the
>>> simulations generate massive quantities of data as they go along.  But
>>> it is certainly an application for which you want as fast networking as
>>> you can afford on the server.
>>>
>>
>> Fwiw, I am wondering of anybody else got pissed off at the nt 4.0 client
>> version only allowing for two concurrent TransmitFile IOCP functions to
>> be allowed at any one time? The nt 4 server allowed for enough
>> concurrent TransmitFile's to blow the non-paged memory. Grrr!
>
> Can't say I've ever actually used NT4 for anything.

Actually I have seen NT 4.0 work rather well under stress testing for a
long time. Working with around 40,000+ concurrent connections in a
contest wrt IOCP vs. Events. The windows events did not do all that
terrible, but IOCP would always end up beating it... However, I could
crash the system wrt using too much non-paged memory. Then there was a
"best practices" paper I was told to read that dealt with so-called
cohort scheduling. I wonder if I can find that old paper. We would bunch
up like actions and execute them in a block. So a big batch of reads
would be executed, instead of a write, read, read, write, write, read,
write, ect...

They would be organized in batches. Actually, I think this is why the
"new" IOCP function can return a bunch of completions in one shot. I
think aio has this as well... Right? Iirc, it is called:

https://learn.microsoft.com/en-us/windows/win32/fileio/getqueuedcompletionstatusex-func

Iirc, this was not available on nt 4...

If I kept the non-paged memory pool stable, the system would not go
down. Well, this was in a stress test, so keep that in mind.

Let me try to find that old paper... Iirc, its name was: Using Cohort
Scheduling and Staged Computation... This is not the paper, damn it!

https://www.epfl.ch/labs/vlsc/wp-content/uploads/2018/07/Cohort-Scheduling.pdf

Oh yeah! I found the actual paper, from Microsoft Research of course...

https://www.deepdyve.com/lp/association-for-computing-machinery/using-cohort-scheduling-to-enhance-server-performance-extended-AzdXP4r1a6

Can anybody else view this? Thanks.

> Or any windows
> release for that matter. In the NT4 timeframe, I was still using large
> IRIX machines and NT was considered a toy. We did have a source license
> for NT4 and modified it to use as one of our supported guest OS' in early
> hypervisor skunkwork (1998/1999) at SGI, so I was, at the time, quite familiar
> with the NTOS portions of windows (which were strikingly similar to the
> VAX VMS internals that I worked with in the early 80's).

On 7/16/2023 10:14 PM, Chris M. Thomasson wrote:
> Cohort Scheduling and Staged Computation

I found the link from microsofts site:

https://i.ibb.co/M66dFD1/image.png