:: Re: [DNG] KDE Desktop Question
トップ ページ
このメッセージを削除
このメッセージに返信
著者: Martin Steigerwald
日付:  
To: dng
題目: Re: [DNG] KDE Desktop Question
Martin Steigerwald - 10.07.24, 19:46:36 CEST:
> That KDE is a resource hog is a myth.


Of course it all boils down what you compare to.

If you compare with AmigaOS, especially Motorola 68k based AmigaOS, then
even just the Linux kernel with a TTY on Alpine Linux *is* a resource hog.

My Amiga 4000 had 128 MiB of RAM in the end and using just AmigaOS native
applications I would not even know what do with that lot of memory. I have
an Apollo Standalone 4 FGPA based computer here which replicates a much
improved version of the original Amiga hardware. It has 512 MiB of RAM.
That is even a completely ridiculous amount of memory for AmigaOS with
usual Amiga applications!

On AmigaOS open a shell window… I joked about it like this: It appears
before you even double clicked the icon! :)

Motorola 68k based AmigaOS did not have a function to swap out memory.
Someone implemented an add-on to swap certain types of memory, but I would
not even have a clue what to use it for.

That written, as soon as you start to use applications that have been
ported over from Linux or Windows… like for example a ported web browser
then you start to see what resource hog is. Except for some early Mosaic
based port of the original Netscape browser which has laid the foundation
for the current Firefox browser. This AMosaic browser ran within a few MiB
(!) of RAM. I believe JavaScript was not even a thing at that time.
Firefox or Chrome/Chromium in themselves are so complex even today there
is not really a working port for AmigaOS. Current browsers are ridiculous
in terms of complexity. Just look at the list of threads they fire up for
viewing a simple web page.

Of course AmigaOS, especially m68k based AmigaOS, does not have memory
isolation between processes and so on. M68k based AmigaOS does not even
have a virtual memory manager¹. Physical address space and that's it. But
it has true preemptive multitasking. It had that back in 1985 already. On
a home computer.

The first version I had, it was AmigaOS 1.2 on an Amiga 500 booted with a
256 KiB ROM – compare that to the ROM size of current X86 based UEFI
firmware! – and a bit less than 840 KiB floppy disk with 512 KiB (!) of RAM
into a graphical environment. No, that is no joke.

On X86 based systems I saw something similar only with an older version of
the QNX Neutrino Realtime Operating System, a superb UNIX based system,
unfortunately proprietary. They had a 1,44 MiB disk booting into a
graphical environment. They had some internet stack and you could start a
simple web browser there. From a 1,44 MiB disk! It was the only operating
system I ever used where if you play music *nothing else* what you do at
the same time will ever introduce a single most tiniest glitch into music
playback – back then on an AMD Athlon XP CPU with a more modern version of
QNX than that from the floppy disk. Linux does not achieve that under all
circumstances. At least not with Pulseaudio, even if under real time
priority.

Everything that is Linux based and has some desktop is a complete resource
hog compared to that.

[1] As much as I like some of the features of the Linux virtual memory
manager I did never really come to terms with a memory manager relying on
an out of memory killer on memory shortage after swap has been exhausted.
But that is what you get when applications allocate virtual address space
like crazy. And there I do have some critique on parts of KDE like Baloo².
Most crazy that our current financial system is based on thin air like
that. Frankly: Linux is not the best operating system kernel I can think
of. Not even close.

[2] Baloo here has 257.0G of virtual address space. It is truly
ridiculous. Its proportional set size currently is 181,5 MiB with a huge
lot of filenames indexed: 1.722.497. But Firefox can be similarly silly:
Just opening my default Firefox profile without even opening a website:
11.1 GiB VSZ. PSS is 253.2 MiB. An empty browser! Many modern apps work
this way. Allocating larger virtual address spaces can improve efficiency
instead of allocating little bits at a time. However the price it that if
processes would actually start to use all of the virtual address space
they allocate => boom! This thin provisioning on memory complicates things
quite a bit.

--
Martin