Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.os.windows-11 > #16688 > unrolled thread

Dimdows Decay Syndrome Continues

Back to article view | Back to alt.comp.os.windows-11

Contents

  Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-01 21:55 +0000
    Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-01 19:07 -0500
      Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-01 20:11 -0500
        Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-02 03:24 +0000
          Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2025-02-02 04:05 +0000
            Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) CrudeSausage <crude@sausa.ge> - 2025-02-02 07:19 -0500
            Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Chris Ahlstrom <OFeem1987@teleworm.us> - 2025-02-02 07:55 -0500
            Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 23:22 +0000
          Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Paul <nospam@needed.invalid> - 2025-02-02 00:08 -0500
            Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Java Jive <java@evij.com.invalid> - 2025-02-02 13:57 +0000
            Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 23:19 +0000
        Re: Dimdows Decay Syndrome Continues Mark Lloyd <not.email@all.invalid> - 2025-02-02 19:26 +0000
          Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-02 14:49 -0500
          Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-02 15:29 -0500
            Re: Dimdows Decay Syndrome Continues chrisv <chrisv@nospam.invalid> - 2025-02-02 15:26 -0600
              Re: Dimdows Decay Syndrome Continues Java Jive <java@evij.com.invalid> - 2025-02-03 02:50 +0000
                Re: Dimdows Decay Syndrome Continues rbowman <bowman@montana.com> - 2025-02-03 04:03 +0000
                Re: Dimdows Decay Syndrome Continues Jeff Barnett <jbb@notatt.com> - 2025-02-02 23:17 -0700
                  Re: Dimdows Decay Syndrome Continues Java Jive <java@evij.com.invalid> - 2025-02-03 13:16 +0000
        Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-07 20:03 -0500
        Re: Dimdows Decay Syndrome Continues Andy Burns <usenet@andyburns.uk> - 2025-02-08 20:12 +0000
          Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-08 21:06 -0500
      Re: Dimdows Decay Syndrome Continues CrudeSausage <crude@sausa.ge> - 2025-02-02 07:11 -0500
        Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 21:34 +0000
          Re: Dimdows Decay Syndrome Continues CrudeSausage <crude@sausa.ge> - 2025-02-07 20:29 -0500
            Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 06:36 +0000
              Kexec (and HyperV) (was: Re: Dimdows Decay Syndrome Continues) vallor <vallor@cultnix.org> - 2025-02-08 08:44 +0000
                Re: Kexec (and HyperV) Paul <nospam@needed.invalid> - 2025-02-08 06:41 -0500
                Re: Kexec (and HyperV) (was: Re: Dimdows Decay Syndrome Continues) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 23:42 +0000
                  Re: Kexec (and HyperV) (was: Re: Dimdows Decay Syndrome Continues) vallor <vallor@cultnix.org> - 2025-02-09 00:25 +0000
              Re: Dimdows Decay Syndrome Continues CrudeSausage <crude@sausa.ge> - 2025-02-08 09:05 -0500
                Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 23:44 +0000
                  Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-08 19:05 -0500
                  Re: Dimdows Decay Syndrome Continues vallor <vallor@cultnix.org> - 2025-02-09 13:58 +0000
                Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-08 21:18 -0500
          Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-07 21:05 -0500
    Re: Dimdows Decay Syndrome Continues Physfitfreak <physfitfreak@gmail.com> - 2025-02-01 21:53 -0600
    Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 21:41 +0000
      Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-07 19:14 -0500
        Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-07 20:26 -0500
          Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-07 20:50 -0500
            Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-07 21:57 -0500
          Re: Dimdows Decay Syndrome Continues Frank Slootweg <this@ddress.is.invalid> - 2025-02-08 15:22 +0000
            Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-08 11:24 -0500
              Re: Dimdows Decay Syndrome Continues Frank Slootweg <this@ddress.is.invalid> - 2025-02-08 18:36 +0000
                Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-08 13:49 -0500
                Re: Dimdows Decay Syndrome Continues Physfitfreak <physfitfreak@gmail.com> - 2025-02-08 13:48 -0600
              Re: Dimdows Decay Syndrome Continues rbowman <bowman@montana.com> - 2025-02-08 19:43 +0000
                Re: Dimdows Decay Syndrome Continues Frank Slootweg <this@ddress.is.invalid> - 2025-02-08 20:41 +0000
                  Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-02-08 16:12 -0500
                  Re: Dimdows Decay Syndrome Continues rbowman <bowman@montana.com> - 2025-02-09 00:35 +0000
          Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-08 23:54 +0000
            Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-08 19:07 -0500
            Re: Dimdows Decay Syndrome Continues rbowman <bowman@montana.com> - 2025-02-09 00:40 +0000
      Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-18 21:51 +0000
        Re: Dimdows Decay Syndrome Continues Joel <joelcrump@gmail.com> - 2025-02-18 17:11 -0500
        Re: Dimdows Decay Syndrome Continues rbowman <bowman@montana.com> - 2025-02-19 01:06 +0000
    Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-17 21:37 +0000
      Re: Dimdows Decay Syndrome Continues Frank Slootweg <this@ddress.is.invalid> - 2025-03-18 13:31 +0000
        Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-03-18 11:08 -0400
      Re: Dimdows Decay Syndrome Continues CrudeSausage <crude@sausa.ge> - 2025-03-18 11:04 -0400
        Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-03-18 19:29 -0400
      Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-02 22:53 +0000
        Re: Dimdows Decay Syndrome Continues Paul <nospam@needed.invalid> - 2025-06-02 23:27 -0400
    Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-27 22:03 +0000
    Re: Dimdows Decay Syndrome Continues Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-09 00:15 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#16907

Paul wrote:

> when I asked it about
> the NTFS file system, rather than answer the question, it told
> me to "get a hex editor and figure it out for yourself". Now,
> isn't that why we invented AI ??? So... helpful. I would not
> have thought of that, using my hex editor and reverse engineering
> NTFS. I suppose the next answer will be "why don't you drive
> to the Public Library and look that up, pal?".

You could buy the Custer book, but it doesn't cover the newer features 
such as reparse points or the altered permission inheritance ...

[toc] | [prev] | [next] | [standalone]

#16922

On Sat, 2/8/2025 3:12 PM, Andy Burns wrote:
> Paul wrote:
> 
>> when I asked it about
>> the NTFS file system, rather than answer the question, it told
>> me to "get a hex editor and figure it out for yourself". Now,
>> isn't that why we invented AI ??? So... helpful. I would not
>> have thought of that, using my hex editor and reverse engineering
>> NTFS. I suppose the next answer will be "why don't you drive
>> to the Public Library and look that up, pal?".
> 
> You could buy the Custer book, but it doesn't cover the newer features such as reparse points or the altered permission inheritance ...
> 

openspecs-windows_protocols-ms-fscc.pdf

IO_REPARSE_TAG_WOF         0x80000017

Used by the Windows Overlay filter, for either WIMBoot
or single-file compression. Server-side interpretation
only, not meaningful over the wire.

IO_REPARSE_TAG_ONEDRIVE    0x80000021      Not used.

I suspect even the Microsoft (derived) documentation
isn't up to date. It's like their WIM spec :-)

The basic idea, is they'll tease you with the value
of the tag, but the rest of it you have to reverse-engineer.

   Paul

[toc] | [prev] | [next] | [standalone]

#16716

On 2025-02-01 7:07 p.m., Joel wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> 
>> Many years ago, a software engineer named Fred Brooks predicted that
>> some systems could get so complex that they would exceed a manageable
>> threshold of complexity, where every attempt to fix a bug would just
>> create new ones.
>>
>> Microsoft passed this point a long time ago. Read this
>> <https://www.zdnet.com/article/windows-11-24h2s-wild-ride-some-fixes-are-in-but-other-bugs-still-linger/>
>> and think: how many times have you heard of this sort of thing, just
>> in the past year? Some choice quotes:
>>
>>     When Microsoft rolled out another Windows 11 24H2 update for
>>     January's Patch Tuesday, instead of fixing existing issues, the
>>     update created more havoc, causing conflicts with audio,
>>     Bluetooth, webcams, and more. But a preview update released on
>>     Jan. 28 finally fixed several glitches -- both old and new.
>>
>> But then qualifies this by saying:
>>
>>     But before you dive into the 2024 update, know that you may run
>>     into some problems and conflicts. The new version has been plagued
>>     by bugs that could prevent you from using Windows reliably and
>>     effectively.
>>
>> So fix some problems, add new ones. Conclusion:
>>
>>     The number of bugs in Windows 11 24H2 also seems greater than in
>>     past annual Windows updates. The ongoing spread of one bug after
>>     another and Microsoft's need to stall the update for many people
>>     both point to a problem with this latest version.
>>
>> Not the first time Windows has had this sort of trouble! It has become
>> a regular occurrence the past few years.
> 
> 
> Good reasons to not use Winblows.

Let's be honest for a second: every operating system introduces new bugs 
when it fixes old ones.

-- 
CrudeSausage
Gab: @CrudeSausage
Telegram: @CrudeSausage
Unapologetic paleoconservative

[toc] | [prev] | [next] | [standalone]

#16875

On Sun, 2 Feb 2025 07:11:42 -0500, CrudeSausage wrote:

> Let's be honest for a second: every operating system introduces new bugs
> when it fixes old ones.

No, reasonably-designed code manages to decrease bugs in existing features 
over time. Bugs in new features will happen, yes.

There is an old engineering adage: complexity arises, not so much from the 
number of components, as from the number of potential interactions between 
them.

Open-source systems tend to have clear separation of functions between 
components, which helps keep unexpected interactions between them, in 
particular, down to a minimum. This allows them to scale to massive 
application deployments, like million-node supercomputers or running the 
entire Internet.

The same cannot be said for Microsoft Windows. The original Windows NT 
concept may have had some kind of conceptual integrity at one point. But 
that has since been lost under an ongoing wave of short-sighted management 
decisions driven entirely by pursuit of immediate profits.

And today, Microsoft’s own experts have no clear idea what Windows is 
doing any more. Why do you think it needs to reboot about five times just 
to do an OS install?

[toc] | [prev] | [next] | [standalone]

#16883

On 2025-02-07 4:34 p.m., Lawrence D'Oliveiro wrote:
> On Sun, 2 Feb 2025 07:11:42 -0500, CrudeSausage wrote:
> 
>> Let's be honest for a second: every operating system introduces new bugs
>> when it fixes old ones.
> 
> No, reasonably-designed code manages to decrease bugs in existing features
> over time. Bugs in new features will happen, yes.
> 
> There is an old engineering adage: complexity arises, not so much from the
> number of components, as from the number of potential interactions between
> them.
> 
> Open-source systems tend to have clear separation of functions between
> components, which helps keep unexpected interactions between them, in
> particular, down to a minimum. This allows them to scale to massive
> application deployments, like million-node supercomputers or running the
> entire Internet.
> 
> The same cannot be said for Microsoft Windows. The original Windows NT
> concept may have had some kind of conceptual integrity at one point. But
> that has since been lost under an ongoing wave of short-sighted management
> decisions driven entirely by pursuit of immediate profits.
> 
> And today, Microsoft’s own experts have no clear idea what Windows is
> doing any more. Why do you think it needs to reboot about five times just
> to do an OS install?

I have to admit those reboots are a nuisance. Of course, Fedora rebooted 
pretty often too. While it doesn't seem to be *necessary* to reboot 
after an update, practically all of them recommended it.

-- 
CrudeSausage
Gab: @CrudeSausage
Telegram: @CrudeSausage
Unapologetic paleoconservative

[toc] | [prev] | [next] | [standalone]

#16890

On Fri, 7 Feb 2025 20:29:39 -0500, CrudeSausage wrote:

> On 2025-02-07 4:34 p.m., Lawrence D'Oliveiro wrote:
>
>> And today, Microsoft’s own experts have no clear idea what Windows is
>> doing any more. Why do you think it needs to reboot about five times
>> just to do an OS install?
> 
> I have to admit those reboots are a nuisance. Of course, Fedora rebooted
> pretty often too.

There are ways to minimize that. Doesn’t RHEL support kexec, which allows 
the old Linux kernel to pass control to the new one without actually 
disrupting the userland?

[toc] | [prev] | [next] | [standalone]

#16892 — Kexec (and HyperV) (was: Re: Dimdows Decay Syndrome Continues)

On Sat, 8 Feb 2025 06:36:16 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <vo6u10$3ue2q$1@dont-email.me>:

> On Fri, 7 Feb 2025 20:29:39 -0500, CrudeSausage wrote:
> 
>> On 2025-02-07 4:34 p.m., Lawrence D'Oliveiro wrote:
>>
>>> And today, Microsoft’s own experts have no clear idea what Windows is
>>> doing any more. Why do you think it needs to reboot about five times
>>> just to do an OS install?
>> 
>> I have to admit those reboots are a nuisance. Of course, Fedora
>> rebooted pretty often too.
> 
> There are ways to minimize that. Doesn’t RHEL support kexec, which
> allows the old Linux kernel to pass control to the new one without
> actually disrupting the userland?

You're thinking of live kernel patching.  kexec_load(2) load a kernel
that you can have execute if the current kernel crashes.  You do this
for debugging, usually.

ObWindows:  There was a post recently about various virtualization
solutions.  Linux subsystem for Windows now uses HyperV, and I'm
wondering if there is a native manager that Windows includes for other
HyperV guests?

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
   OS: Linux 6.13.1 Release: Mint 22.1 Mem: 258G
   "These shoes look like Frankenstein's hand-me-downs."

[toc] | [prev] | [next] | [standalone]

#16894 — Re: Kexec (and HyperV)

On Sat, 2/8/2025 3:44 AM, vallor wrote:
> On Sat, 8 Feb 2025 06:36:16 -0000 (UTC), Lawrence D'Oliveiro
> <ldo@nz.invalid> wrote in <vo6u10$3ue2q$1@dont-email.me>:
> 
>> On Fri, 7 Feb 2025 20:29:39 -0500, CrudeSausage wrote:
>>
>>> On 2025-02-07 4:34 p.m., Lawrence D'Oliveiro wrote:
>>>
>>>> And today, Microsoft’s own experts have no clear idea what Windows is
>>>> doing any more. Why do you think it needs to reboot about five times
>>>> just to do an OS install?
>>>
>>> I have to admit those reboots are a nuisance. Of course, Fedora
>>> rebooted pretty often too.
>>
>> There are ways to minimize that. Doesn’t RHEL support kexec, which
>> allows the old Linux kernel to pass control to the new one without
>> actually disrupting the userland?
> 
> You're thinking of live kernel patching.  kexec_load(2) load a kernel
> that you can have execute if the current kernel crashes.  You do this
> for debugging, usually.
> 
> ObWindows:  There was a post recently about various virtualization
> solutions.  Linux subsystem for Windows now uses HyperV, and I'm
> wondering if there is a native manager that Windows includes for other
> HyperV guests?
> 

That would be on the Professional SKU, at a minimum.

   [Picture]

    https://i.postimg.cc/NjzsHk9M/Hyper-V-on-parade.gif

   Paul

[toc] | [prev] | [next] | [standalone]

#16912 — Re: Kexec (and HyperV) (was: Re: Dimdows Decay Syndrome Continues)

On 8 Feb 2025 08:44:20 GMT, vallor wrote:

> On Sat, 8 Feb 2025 06:36:16 -0000 (UTC), Lawrence D'Oliveiro
> <ldo@nz.invalid> wrote in <vo6u10$3ue2q$1@dont-email.me>:
> 
>> Doesn’t RHEL support kexec, which
>> allows the old Linux kernel to pass control to the new one without
>> actually disrupting the userland?
> 
> You're thinking of live kernel patching.  kexec_load(2) load a kernel
> that you can have execute if the current kernel crashes.  You do this
> for debugging, usually.

Bit more than that <https://manpages.debian.org/kexec_load(2)>:

    The kexec_load() system call loads a new kernel that can be
    executed later by reboot(2).

And one of the functions of the latter
<https://manpages.debian.org/reboot(2)> is:

    LINUX_REBOOT_CMD_KEXEC
      (RB_KEXEC, 0x45584543, since Linux 2.6.13). Execute a kernel
      that has been loaded earlier with kexec_load(2).

[toc] | [prev] | [next] | [standalone]

#16917 — Re: Kexec (and HyperV) (was: Re: Dimdows Decay Syndrome Continues)

On Sat, 8 Feb 2025 23:42:11 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <vo8q4j$8tqo$2@dont-email.me>:

> On 8 Feb 2025 08:44:20 GMT, vallor wrote:
> 
>> On Sat, 8 Feb 2025 06:36:16 -0000 (UTC), Lawrence D'Oliveiro
>> <ldo@nz.invalid> wrote in <vo6u10$3ue2q$1@dont-email.me>:
>> 
>>> Doesn’t RHEL support kexec, which allows the old Linux kernel to pass
>>> control to the new one without actually disrupting the userland?
>> 
>> You're thinking of live kernel patching.  kexec_load(2) load a kernel
>> that you can have execute if the current kernel crashes.  You do this
>> for debugging, usually.
> 
> Bit more than that <https://manpages.debian.org/kexec_load(2)>:
> 
>     The kexec_load() system call loads a new kernel that can be executed
>     later by reboot(2).
> 
> And one of the functions of the latter
> <https://manpages.debian.org/reboot(2)> is:
> 
>     LINUX_REBOOT_CMD_KEXEC
>       (RB_KEXEC, 0x45584543, since Linux 2.6.13). Execute a kernel that
>       has been loaded earlier with kexec_load(2).

I don't see your point.  (That's what I said.)

It doesn't load "without disturbing the userland"...

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
   OS: Linux 6.13.1 Release: Mint 22.1 Mem: 258G
   "Why is "easy listening" so hard to listen to?"

[toc] | [prev] | [next] | [standalone]

#16897

On 2025-02-08 1:36 a.m., Lawrence D'Oliveiro wrote:
> On Fri, 7 Feb 2025 20:29:39 -0500, CrudeSausage wrote:
> 
>> On 2025-02-07 4:34 p.m., Lawrence D'Oliveiro wrote:
>>
>>> And today, Microsoft’s own experts have no clear idea what Windows is
>>> doing any more. Why do you think it needs to reboot about five times
>>> just to do an OS install?
>>
>> I have to admit those reboots are a nuisance. Of course, Fedora rebooted
>> pretty often too.
> 
> There are ways to minimize that. Doesn’t RHEL support kexec, which allows
> the old Linux kernel to pass control to the new one without actually
> disrupting the userland?

I don't know, it might. Like I said, you don't have to reboot but they 
recommend it. We expect that kind of behaviour from Windows, so it's not 
that cumbersome when it happens in Linux too.

-- 
CrudeSausage
Gab: @CrudeSausage
Telegram: @CrudeSausage
Unapologetic paleoconservative

[toc] | [prev] | [next] | [standalone]

#16913

On Sat, 8 Feb 2025 09:05:27 -0500, CrudeSausage wrote:

> On 2025-02-08 1:36 a.m., Lawrence D'Oliveiro wrote:
>
>> Doesn’t RHEL support kexec, which
>> allows the old Linux kernel to pass control to the new one without
>> actually disrupting the userland?
> 
> I don't know, it might.

The last openSUSE install I did, some years ago, I remember it switched 
almost seamlessly from running off the installation media to running off 
the just-created (minimal) installation, and continued adding packages 
from there. There was no perceptible reboot stage at all.

Just to point out this is a common Linux kernel feature, not something 
specific to a particular distro.

[toc] | [prev] | [next] | [standalone]

#16915

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sat, 8 Feb 2025 09:05:27 -0500, CrudeSausage wrote:
>> On 2025-02-08 1:36 a.m., Lawrence D'Oliveiro wrote:
>>
>>> Doesn’t RHEL support kexec, which
>>> allows the old Linux kernel to pass control to the new one without
>>> actually disrupting the userland?
>> 
>> I don't know, it might.
>
>The last openSUSE install I did, some years ago, I remember it switched 
>almost seamlessly from running off the installation media to running off 
>the just-created (minimal) installation, and continued adding packages 
>from there. There was no perceptible reboot stage at all.
>
>Just to point out this is a common Linux kernel feature, not something 
>specific to a particular distro.


"Perceptible reboot stage"?  What the hell does that mean?  It either
did or did not reboot.

-- 
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent.  States are
liable for denying needed abortions, e.g. TX.

[toc] | [prev] | [next] | [standalone]

#16934

On Sat, 8 Feb 2025 23:44:41 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote in <vo8q98$8tqo$3@dont-email.me>:

> On Sat, 8 Feb 2025 09:05:27 -0500, CrudeSausage wrote:
> 
>> On 2025-02-08 1:36 a.m., Lawrence D'Oliveiro wrote:
>>
>>> Doesn’t RHEL support kexec, which allows the old Linux kernel to pass
>>> control to the new one without actually disrupting the userland?
>> 
>> I don't know, it might.
> 
> The last openSUSE install I did, some years ago, I remember it switched
> almost seamlessly from running off the installation media to running off
> the just-created (minimal) installation, and continued adding packages
> from there. There was no perceptible reboot stage at all.
> 
> Just to point out this is a common Linux kernel feature, not something
> specific to a particular distro.

Not sure why that would need kexec -- more likely, it used
chroot(8) or pivot_root(8).

-- 
-v System76 Thelio Mega v1.1 x86_64 NVIDIA RTX 3090 Ti
   OS: Linux 6.13.1 Release: Mint 22.1 Mem: 258G
   "There's no future in time travel"

[toc] | [prev] | [next] | [standalone]

#16923

On Sat, 2/8/2025 9:05 AM, CrudeSausage wrote:
> On 2025-02-08 1:36 a.m., Lawrence D'Oliveiro wrote:
>> On Fri, 7 Feb 2025 20:29:39 -0500, CrudeSausage wrote:
>>
>>> On 2025-02-07 4:34 p.m., Lawrence D'Oliveiro wrote:
>>>
>>>> And today, Microsoft’s own experts have no clear idea what Windows is
>>>> doing any more. Why do you think it needs to reboot about five times
>>>> just to do an OS install?
>>>
>>> I have to admit those reboots are a nuisance. Of course, Fedora rebooted
>>> pretty often too.
>>
>> There are ways to minimize that. Doesn’t RHEL support kexec, which allows
>> the old Linux kernel to pass control to the new one without actually
>> disrupting the userland?
> 
> I don't know, it might. Like I said, you don't have to reboot but they recommend it. We expect that kind of behaviour from Windows, so it's not that cumbersome when it happens in Linux too.
> 

Your personal policy may depend on your machine.

On a server with ECC and the background scrubber engaged,
you might laugh at reboots as "unnecessary" and "bourgeois".

On a desktop system where the RAM is protected by nothing,
rebooting is a good way of refreshing the RAM image.

Even if computers had static RAM instead of dynamic RAM,
the bus signal integrity means the error rate is not zero.
With static RAM, the memory might be a tiny bit more
resistant to cosmic ray events.

   Paul

[toc] | [prev] | [next] | [standalone]

#16885

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sun, 2 Feb 2025 07:11:42 -0500, CrudeSausage wrote:
>
>> Let's be honest for a second: every operating system introduces new bugs
>> when it fixes old ones.
>
>No, reasonably-designed code manages to decrease bugs in existing features 
>over time. Bugs in new features will happen, yes.
>
>There is an old engineering adage: complexity arises, not so much from the 
>number of components, as from the number of potential interactions between 
>them.
>
>Open-source systems tend to have clear separation of functions between 
>components, which helps keep unexpected interactions between them, in 
>particular, down to a minimum. This allows them to scale to massive 
>application deployments, like million-node supercomputers or running the 
>entire Internet.
>
>The same cannot be said for Microsoft Windows. The original Windows NT 
>concept may have had some kind of conceptual integrity at one point. But 
>that has since been lost under an ongoing wave of short-sighted management 
>decisions driven entirely by pursuit of immediate profits.
>
>And today, Microsoft’s own experts have no clear idea what Windows is 
>doing any more. Why do you think it needs to reboot about five times just 
>to do an OS install?


https://www.merriam-webster.com/dictionary/behemoth

behemoth noun

2: something of monstrous size, power, or appearance
[as in] a behemoth truck

------------------------------------------------------------------------------

That's what Windows is.  Even Win10 is bloated *as fuck*.  It just
melds well with hardware above a certain standard.  And Win11 is only
more bloated.  Linux is salvation, for one who treasures the PC.

-- 
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent.  States are
liable for denying needed abortions, e.g. TX.

[toc] | [prev] | [next] | [standalone]

#16694

On 2/1/25 3:55 PM, Lawrence D'Oliveiro wrote:
> Many years ago, a software engineer named Fred Brooks predicted that
> some systems could get so complex that they would exceed a manageable
> threshold of complexity, where every attempt to fix a bug would just
> create new ones.
> 
> Microsoft passed this point a long time ago. Read this
> <https://www.zdnet.com/article/windows-11-24h2s-wild-ride-some-fixes-are-in-but-other-bugs-still-linger/>
> and think: how many times have you heard of this sort of thing, just
> in the past year? Some choice quotes:
> 
>      When Microsoft rolled out another Windows 11 24H2 update for
>      January's Patch Tuesday, instead of fixing existing issues, the
>      update created more havoc, causing conflicts with audio,
>      Bluetooth, webcams, and more. But a preview update released on
>      Jan. 28 finally fixed several glitches -- both old and new.
> 
> But then qualifies this by saying:
> 
>      But before you dive into the 2024 update, know that you may run
>      into some problems and conflicts. The new version has been plagued
>      by bugs that could prevent you from using Windows reliably and
>      effectively.
> 
> So fix some problems, add new ones. Conclusion:
> 
>      The number of bugs in Windows 11 24H2 also seems greater than in
>      past annual Windows updates. The ongoing spread of one bug after
>      another and Microsoft's need to stall the update for many people
>      both point to a problem with this latest version.
> 
> Not the first time Windows has had this sort of trouble! It has become
> a regular occurrence the past few years.


The reason is Microsoft hired people who didn't fire "DFS" type employees.

United States has been suffering from that problem since Reagan era.

[toc] | [prev] | [next] | [standalone]

#16876

On Sat, 1 Feb 2025 21:55:15 -0000 (UTC), I wrote:

> Many years ago, a software engineer named Fred Brooks predicted that
> some systems could get so complex that they would exceed a manageable
> threshold of complexity, where every attempt to fix a bug would just
> create new ones.
>
> Microsoft passed this point a long time ago.

The sorry Dimdows 11 saga continues
<https://www.zdnet.com/article/windows-11s-bug-fixing-update-is-making-things-worse/>.
This latest update is actually *adding* more net bugs on top of the
previous revision of the OS.

Have we gone beyond the Brooks threshold, and now entered a Kessler
Syndrome of runaway bug proliferation, where instead of merely
creating about one new bug for every one fixed, the “fixes” are
actually adding to an exponential decline in Microsoft’s software
quality?

[toc] | [prev] | [next] | [standalone]

#16880

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sat, 1 Feb 2025 21:55:15 -0000 (UTC), I wrote:
>
>> Many years ago, a software engineer named Fred Brooks predicted that
>> some systems could get so complex that they would exceed a manageable
>> threshold of complexity, where every attempt to fix a bug would just
>> create new ones.
>>
>> Microsoft passed this point a long time ago.
>
>The sorry Dimdows 11 saga continues
><https://www.zdnet.com/article/windows-11s-bug-fixing-update-is-making-things-worse/>.
>This latest update is actually *adding* more net bugs on top of the
>previous revision of the OS.
>
>Have we gone beyond the Brooks threshold, and now entered a Kessler
>Syndrome of runaway bug proliferation, where instead of merely
>creating about one new bug for every one fixed, the “fixes” are
>actually adding to an exponential decline in Microsoft’s software
>quality?


This is nothing new, public beta testing, just run 23H2 or better yet,
upgrade to Linux.

-- 
Joel W. Crump

Amendment XIV
Section 1.

[...] No state shall make or enforce any law which shall
abridge the privileges or immunities of citizens of the
United States; nor shall any state deprive any person of
life, liberty, or property, without due process of law;
nor deny to any person within its jurisdiction the equal
protection of the laws.

Dobbs rewrites this, it is invalid precedent.  States are
liable for denying needed abortions, e.g. TX.

[toc] | [prev] | [next] | [standalone]

#16882

On Fri, 2/7/2025 7:14 PM, Joel wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 1 Feb 2025 21:55:15 -0000 (UTC), I wrote:
>>
>>> Many years ago, a software engineer named Fred Brooks predicted that
>>> some systems could get so complex that they would exceed a manageable
>>> threshold of complexity, where every attempt to fix a bug would just
>>> create new ones.
>>>
>>> Microsoft passed this point a long time ago.
>>
>> The sorry Dimdows 11 saga continues
>> <https://www.zdnet.com/article/windows-11s-bug-fixing-update-is-making-things-worse/>.
>> This latest update is actually *adding* more net bugs on top of the
>> previous revision of the OS.
>>
>> Have we gone beyond the Brooks threshold, and now entered a Kessler
>> Syndrome of runaway bug proliferation, where instead of merely
>> creating about one new bug for every one fixed, the “fixes” are
>> actually adding to an exponential decline in Microsoft’s software
>> quality?
> 
> 
> This is nothing new, public beta testing, just run 23H2 or better yet,
> upgrade to Linux.
> 

"The latest issue centers around the Windows 11 24H2 preview update"
                                                     ^^^^^^^

Yeah, we don't install those. Those are voluntary, in that you click
that if you think there is something in that update for you.

It will appear again on Patch Tuesday, which would be the 11th of February.

A valuable place to gather intelligence, is the Reliability Monitor,
which keeps certain kinds of failures in a chart form. Nobody seems to
have bothered in that article, to check for messages in there.

That's an alternative to looking in EventVwr.msc .

TO get there, open Settings and type "Relia" into the top search bar.

   Paul

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | alt.comp.os.windows-11

csiph-web