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

Groups > comp.os.linux.advocacy > #684833 > unrolled thread

Dimdows Decay Syndrome Continues

Back to article view | Back to comp.os.linux.advocacy

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: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) DFS <guhnoo-basher@linux.advocaca> - 2025-02-02 16:05 -0500
            Re: The Dominance Of Linux (was Re: Dimdows Decay Syndrome Continues) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 23:17 +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: Onslaught of Linux kernel regressions (was Dimdows Decay Syndrome Continues) DFS <guhnoo-basher@linux.advocaca> - 2025-02-02 21:23 -0500
      Re: Onslaught of Linux kernel regressions (was Dimdows Decay Syndrome Continues) Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-02-07 21:36 +0000
    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

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

#684907

On 2025-02-03 06:17, Jeff Barnett wrote:
> On 2/2/2025 7:50 PM, Java Jive wrote:
>> On 2025-02-02 21:26, chrisv wrote:
>>> Paul wrote:
>>>
>>>> Similarly, the AI doing the Google searches, is doing
>>>> a shit job, and I'm now looking at a situation were
>>>> I don't get any help at all from the Internet any more.
>>>>
>>>> AI is definitely a "mission accomplished" thing. It's
>>>> trashed the Internet. Good work.
>>>
>>> It's not done until it's trashed human society.  Eventually we'll have
>>> no reason to think, at all.
>>
>> That's nonsense  ...  It's like saying that because we have 
>> calculators we don't need to be able to do any mental arithmetic, but 
>> you always need to be able to check that the result you get is 
>> reasonable to be sure that you haven't miskeyed something while 
>> entering the calculation.   Or it's like saying that because we have 
>> navigation apps no-one will need to read maps or think about what the 
>> app is telling them to do. Remember the German couple who drove off 
>> the end of a pier, and, IMS, drowned, because their navigation app 
>> told them to?!  Or the Euro continental lorry drivers who enter 
>> "Gibraltar" into their nav apps and end up in a tiny English village 
>> that happens to have the same name?! Didn't any penny drop when they 
>> had to take a Channel ferry?  Etc, etc.
> 
> As best I only see, a significant portion of the younger generations can 
> neither do simple arithmetic nor 1-step logical deductions (or the 
> informal equivalents or approximations). In other words, they cannot 
> verify or validate much of the information presented to them. 

That's not a generational thing, there are people like that in every 
generation.

> I see, as 
> a result, such moves as not accepting cash at many stories.
> 
> I asked an owner of a fast food place why. The answer: The schools 
> didn't teach them arithmetic and I think they are too old to learn! I 
> also recall an experience a few years ago. I selected some supplies at a 
> store in Marina del Rey (part of greater LA) and approached the cash 
> register where a vacant looking 20 something young lady was the cashier. 
> She laboriously rings up the items and the total comes to $19.99. I take 
> out my wallet, hand her a $20 bill and apologize for not having anything 
> smaller. She says nothing, does not crack a smile, and remains frozen 
> until the register tells her to give me a penny back. Still no reaction.

Again, there are dumb-asses in every generation.

> So you really think we, collectively, will be able to profit from 
> information that allows us to double check our computers? 

My post to which you are replying gave examples of what can happen if we 
don't.

> These are the 
> same folks who are frightened by vaccines and community health. (I know 
> there is a small number of people who have predictable poor reactions, 
> but they're generally not the ones spouting conspiracy theories.)

Yes, there's one of those living near to me, but, at a guess, he's in 
he's 80s, so, again, not a generational thing.  [His wife, a nice, kind 
old dear, had a severe stroke a week or two after having a covid vaccine 
and is now mentally much impaired.  Understandably, but most probably 
incorrectly, he links the vaccine and the stroke, whereas in truth she 
may well have had the stroke even if she had not had the vaccine 
beforehand.  What happened to her is tragic, and they both deserve every 
sympathy, but in all probability the two events are unrelated except by 
coincidence.]

> The promise that connectivity (the internet) would improve society and 
> its human inhabitants has been shown false. Rather, it has led to 
> intellectually laziness and polarization. Non-vetted results are repeat 
> as gospel and we are all manipulated and exploited. 

Again, not a generational thing, people used to be just as 
undiscriminating reading newspaper reports and watching TV reports.  The 
thing that the internet has changed is the speed of it all.

> The point is that 
> the vast majority of us are entrenched in this madness and our brain's 
> off switch has been thrown.
> 
> We do not regain rationality when presented with quality information 
> unless we agree with it before it is presented to us. When I say "we" I 
> included all of us who have spent our lives using our brain; we all seem 
> to have these blind spots where we would rather believe than think.

The problem has always been compromising between saving mental effort  - 
  so that you don't go through the laborious process of reinventing the 
wheel every time you need to use one, you just reuse what is already 
known  -  and assessing new information whose usefulness is as yet 
unknown.  No person or the wider society of which he/she is part could 
ever make progress at either extreme of rethinking everything all the 
time or taking everything new as 'good' without questioning it, the best 
path forward has always been a compromise between those two extremes. 
The internet has made this problem more obvious and thus magnified its 
apparent importance, but it's always been a problem.

-- 

Fake news kills!

I may be contacted via the contact address given on my website: 
www.macfh.co.uk

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

#685294

Paul <nospam@needed.invalid> wrote:

>The CoPilot gave me a real golf whiff answer yesterday. I could
>not believe an AI could write an answer like that. It did not
>say "Sorry, I don't know the answer". But 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?".


https://i.imgur.com/L71761l.png


My take:  it's pretty typical M$.  They aren't gonna let their AI bot
give you that info, but then again it does know that at the end of the
day, nothing can prevent reverse engineering, it's even a necessity
with obsolete systems to emulate, for example, I'm reasonably sure if
I pirate the original Super Mario Bros. NES game, in an emulator,
Nintendo will let it slide.

-- 
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]

#685390

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]

#685419

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]

#684849

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]

#685280

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]

#685303

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]

#685318

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]

#685330 — 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]

#685336 — 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]

#685406 — 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]

#685415 — 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]

#685341

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]

#685407

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]

#685411

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]

#685467

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]

#685420

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]

#685308

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]

#684844

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]

#684880 — Re: Onslaught of Linux kernel regressions (was Dimdows Decay Syndrome Continues)

On 2/1/2025 4: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.


Conclusion: OS's are extremely complicated pieces of code that will 
never be "perfect".


> Not the first time Windows has had this sort of trouble! It has become
> a regular occurrence the past few years.


The large GuhNoo part of your lamebrain seems to have completely 
forgotten the Linux kernel alone has suffered many thousands of 
regressions through the years.

"It’s a regression if something running fine with one Linux kernel works 
worse or not at all with a newer version."

There's so many that academics at major institutions write papers about 
them:

https://static.lwn.net/images/pdf/kernel_regressions.pdf  (see Table 1)

https://arxiv.org/abs/2411.02091

https://mirror.linux.org.au/pub/linux.conf.au/2004/papers/41-janis-johnson-reghunt_kernel.pdf

https://dl.acm.org/doi/10.1145/3634737.3637642



It's clear you're being true to yourself and have decided to identify as 
a lying Linux idiot.

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

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

Back to top | Article view | comp.os.linux.advocacy

csiph-web