Re: Byte ordering

On 17/10/2024 03:19, George Neuner wrote:

On Wed, 16 Oct 2024 09:17:03 +0200, David Brown
<david.brown@hesbynett.no> wrote:
 

On 16/10/2024 07:36, Terje Mathisen wrote:

George Neuner wrote:

On Tue, 15 Oct 2024 18:40 +0100 (BST), jgd@cix.co.uk (John Dallman)
wrote:
>

In article <vekb2f$1co97$6@dont-email.me>, ldo@nz.invalid (Lawrence
D'Oliveiro) wrote:
>

On the other hand, some stubborn holdouts are still fond of
microkernels -- you just have to say the whole idea is pointless,
and they come out of the woodwork in a futile attempt to disagree

>
The idea is impractical, not pointless. A hybrid kernel gives most of
the
advantages of a microkernel to its developers, and avoids the need for
lots of context switches. It doesn't let you easily replace low-level OS
components, but not many people actually want that.

>
Actually, I think there are a whole lot of people who can't afford
non-stop server hardware but would greatly appreciate not having to
waste time with a shutdown/reboot every time some OS component gets
updated.
>
YMMV.

>
This is _exactly_ (one of) the problem(s) cloud infrastructure solves:
As soon as you have more than a single instance of a particular
server/service, then you replace them in groups so that the service sees
zero downtime even though all the servers have been updated/replaced.
>

>
That's fine - /if/ you have a service that can easily be spread across
multiple systems, and you can justify the cost of that.  Setting up a
database server is simple enough.
>
Setting up a database server along with a couple of read-only
replications is harder.  Adding a writeable failover secondary is harder
still.  Making sure that everything works /perfectly/ when the primary
goes down for maintenance, and that everything is consistent afterwards,
is even harder.  Being sure it still all works even while the different
parts have different versions during updates typically means you have to
duplicate the whole thing so you can do test runs.  And if the database
server is not open source, your license costs will be absurd, compared
to what you actually need to provide the service - usually just one
server instance.
>
Clouds do nothing to help any of that.
>
But clouds /do/ mean that your virtual machine can be migrated (with
zero, or almost zero, downtime) to another physical server if there are
hardware problems or during hardware maintenance.  And if you can do
easy snapshots with your cloud / VM infrastructure, then you can roll
back if things go badly wrong.  So you have a single server instance,
you plan a short period of downtime, take a snapshot, stop the service,
upgrade, restart.  That's what almost everyone does, other than the
/really/ big or /really/ critical service providers.

 For various definitions of "short period of downtime".  8-)

Yes, indeed.

 Fortunately, Linux installs updates - or stages updates for restart -
much faster than Windoze.  But rebooting to the point that all the
services are running still can take several minutes.
 

My experience is that the updates on Linux servers are usually fast (for desktops they can be slow, but that is usually because you have far more and bigger programs).  Updates for virtual machines are particularly fast because you generally have a minimum of programs in the VM. Restarts are also fast for virtual machines - physical servers are often slow to restart, sometimes taking many minutes before they get to the point of starting the OS boot.

That can feel like an eternity when it's the only <whatever> server in
a small business.

Sure.  But for most small businesses, it's not hard to find off-peak times when you can have hours of downtime without causing a problem.