Enrico Weigelt, metux IT consult - 21.02.24, 19:21:15 CET:
> On 19.02.24 10:54, Martin Steigerwald wrote:
[…]
> > Hello world unstripped with gcc compiled C source is
> > about 15,5 KiB. Even stripped it is about 14,1 KiB.
>
> Dynamically or statically linked ?

Dynamically linked. According to "readelf" there are a lot more ELF
sections than in the minimal fasm example. Also according to "strace" or
"perf trace" it calls a quite some more system calls like for example
mprotect().

> Did you try the same with some embedded libc ?

Not yet, I expect the binary to be much smaller with musl. I also read in
German language Linux-Magazin about nolibc which is in kernel and how that
can be used to reduce binary size.

Also for fasm there is also an example that uses libc. I did not assemble
that so far.

So there is still more room for research.

> > AmigaOS boots from hard disk faster than Linux boots from SSD
>
> But hardware is pretty trivial compared to today's machines (just
> consider what it takes to get the CPU into protected more and set up
> page tables, etc, etc ... not even mentioning peripherals) and very
> static.

Still I think there is some appeal to the plea of Nikolaus Wirth.

> > However… as Nikolaus Wirth
> > correctly states that still does not explain the bloat in current
> > software. Even Minix could be booted from floppy disk back in my Amiga
> > 500 times. On the Amiga :).
>
> Linux did that once, too. But back then it only supported a small
> fraction of the HW it does today, and there even was such complex HW
> (like eg. GPUs).

Yeah, maybe that is part of the reason. Back in Amiga times they developed
the Amiga chip set basically in a garage with a very small and dedicated
team. I bet nowadays more than 100 people are working on a GPU.

There are some who still work on old, simpler designs. Like the Apollo
people put a complete Amiga chip set + CPU into an FGPA. And then extended
it. So that the graphics and sound chips can do more and they call their
CPU 68080 instead of the last one used in classic Amigas, the 68060. They
carefully added new instructions where it makes sense to them¹.

[1] Just recently: FLOAT or DOUBLE to Unsigned Integer.

http://apollo-core.com/knowledge.php?b=1&note=40490

> But yes: HW designers are usually doing a pretty bad job in clean
> interface design. Most peripherals (at least in the pc/server field)
> could be fine with standardized interfaces/protocols (eg. USB), and it
> wouldn't even cost an really notable greater portion on transistors.
>
> As OS developers, we just need to cope with the HW we have :(

I think in Linux it is not just the hardware, just the drivers. But yes,
of course that is a big part of it.

Linux has an extreme ton of features. And it appears they have users,
otherwise they would not have been introduced. For example control groups,
great for limiting workloads. But still even the reworked version 2 is
quite complex. And I read about new features often, something not even
understanding what they are for.

> > A good one is a lack of taking the time to think through
> > things *before* and *during* writing code.
>
> Indeed, OTOH in many FOSS projects (especially the kernel) we do take
> that time and also do continious refactoring.

That is good. And I enjoy some of those here and there. Also I enjoy some
pretty impressive performance improvements like Kate (KDE text editor)
being able to search and find in +50 MiB text file almost instantly. This
took a lot longer before.

> > All three month a new Linux kernel.
>
> "New" is pretty relative here. Most of the time it's either fixes or
> performance improvements, or new drivers (and also lots of refactoring
> along the way).
>
> > Do you understand the complete Linux kernel?
>
> Obviously not the complete one, but a huge part of the pieces I'm
> actually using (my understanding usually stops on certain really low-
> level cpu-arch/model specific aspects, as well as some HW details).
> One of the biggest shares of the code base is dealing with crappy HW.

Thanks for this different perspective. Will think about it.

> > It would be very beneficial to reduce the pace.
>
> And wait much longer for fixes ?

It ain't not just fixes. Not at all. Don't get me wrong. I am happy about
new features as well. I really started testing out BCacheFS already and I
am looking forward to use it more.

> Well, you're free to use LTS kernels.

Maybe that would be an idea, but I admit I also like new features like
BCacheFS and test them early on. For example for the Linux Performance
analysis and tuning trainings I give.

On the other hand about any modern filesystem Linux kernel module takes
more space than the complete Amiga Kickstart operating system kernel.
Sometimes three times as much. Yes, they can do more and yes, original
Amiga filesystem is not really good with performance.

Still I think it is good to really read and take to heart what Nikolaus
Wirth wrote. I don't know an easy way out to reduce some of the pace, but
I still think it could be beneficial.

> > During my little fun project I looked at how Linux
> > takes parameters for syscalls from X86_64 registers. It is complete
> > insanity.
>
> x86 is complete insanity, indeed.

Yes. How they named the registers is crazy to begin with.

> > How can one design a processor and a syscall interface this way?
>
> I'm still hoping for The Mill ... :o

The Mill?

> > IMHO there are leaner and better operating system designs.
>
> I hope you don't count Oberon in here ;-)

No, I did not yet look more closely at Oberon. I refer more to what
Nikolaus Wirth wrote before introducting Oberon as a possible solution.
However I was for example impressed by the micro kernel operating system
QNX, unfortunately not free software, back then when I ran it on an Athlon
XP machine. When it played sound it played sound. Glitch free. No matter
what else I did. Meanwhile it is not easy on Linux to bring glitches into
sound playback, but still possible.

I don't know exactly where QNX is today.

> Actually used to be passioned Oberon developer, decades ago. It
> certainly has a lot of good concepts, but not suited for wide use.

That is the issue I mentioned. Most of these alternatives are not suited
for wide use. And there you have part of what you mentioned again: Drivers
and hardware interfaces.

That is why I am on Linux for my desktops. And currently servers as well.

Anyway, what was missing for you in Oberon?

You certainly have a point there. However I still think Nikolaus Wirth has
one as well.

Best,
--
Martin