Groups | Search | Server Info | Login | Register
Groups > comp.lang.misc > #11299
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Newsgroups | comp.lang.misc |
| Subject | Re: Algol 68 / Genie - opinions on local procedures? |
| Date | 2025-10-04 01:11 +0000 |
| Organization | To protect and to server |
| Message-ID | <10bps7v$4407$1@paganini.bofh.team> (permalink) |
| References | (3 earlier) <1080dts$2u7bm$2@dont-email.me> <1080hed$3f6hn$1@dont-email.me> <10832ej$3knom$1@dont-email.me> <10835na$1m96$7@dont-email.me> <1085jvi$7gcv$1@dont-email.me> |
Andy Walker <anw@cuboid.co.uk> wrote:
> On 20/08/2025 01:43, Lawrence D’Oliveiro wrote:
> [I wrote:]
>>> From time to time I wonder what would happen if we ran
>>> 7th Edition Unix on a modern computer.
>> The Linux kernel source is currently over 40 million lines, and I
>> understand the vast majority of that is device drivers.
>
> You seem to be making Janis's point, but that doesn't seem to
> be your intention?
>
>> If you were to run an old OS on new hardware, that would need drivers for
>> that new hardware, too.
>
> Yes, but what is so special about a modern disc drive, monitor,
> keyboard, mouse, ... that it needs "the vast majority" of 40M lines more
> than its equivalent for a PDP-11? Does this not again make Janis's point?
Lawrence gave a good list of things, but let me note few additional
aspects. First there is _a lot_ of different drivers. In PDP-11
times there were short list of available devices. Now there is a lot
of different devices on the market and each one potentially need a
specialised driver in the kernel. Linux actually make a good job here:
typical driver handles a group of similar devices and various tables and
conditonals in the code take care of differences between devices in the
group. But still, there is a lot of different driver and generality
of a single driver means it is more complicated than driver for a
single device.
On my desktop kernel boot messages say "14342K kernel code". Nominally
assuming 10 bytes per source line it means 1.4 milions of lines of
running code, so relatively small part of total kernel source.
Note that this is generic kernel provided by distribution (Debian)
which is supposed to run "on any PC". Compiling specialised
kernel one can exclude various features from the kernel. I did
not try this with recent kernels for PC, but past experience indicates
that by exluding features and device support one can get substantially
smaller kernel. I would guess 4MB for PC kernel with reasonnable
set of features and possibly smaller if one decides to drop essential
features.
Second, modern devices frequently require complex setup control.
Let me mention issue that probably does not affect PC-s but indicate
tendency. Namely, I deal with small microcontrolles. One may wish
to attach a LCD screen to such microcontroller. To setup one
particular screen one need send about 100 numerical parameters to
the chip controlling the display. Some parameters can be taken
from a simple table, but some may vary and need to be computed
by initialization routine. Once initialized display behaves as
dumb frame buffer, so is rather simple to drive. Compared to
that initialization code is surprisingly complex. Coming back
to PC devices, such devices frequently have complex initialization.
Actual operation may be more complex than earlier devices.
Simply, device manufactures tend to move complexity to driver
software.
Third, we live in era of multicore machines. OS is supposed to
efficiently utilize all cores and share work between them. This
requires a lot of carefuly placed locks and when possible special
code seqences using ordinary or atomic instructions that work
when run in parallel on different cores. That leads to bigger
code, especially at source level.
> Granted that the advent of 32- and 64-bit integers and addresses
> makes some programming much easier, and that we can no longer expect
> browsers and other major tools to fit into 64+64K bytes, is the actual
> bloat in any way justified?
I think that Linux kernel actually is somewhat reasonable range.
Early version of Linux would take say 1MB of 8MB available in the
machine. Modern Linux takes more, but it is tiny part of the
whole available memory. And given growth in functionality growth
is size of kernel binary does not look so bad.
I think that comparisons with early mainframes or PDP-11 are
misleading in the sence that on early machines programmes struggled
to fit programs into avaliable memory. Common technique was keeping
data on disc and having multiple sequential passes. Program
itself could be split into several overlays. Use of overlays
essentially vanished with introduction of virtual memory coupled
with multimegabyte real RAM. More relevant are comparisons
with VAX and early Linux.
AFAICS bloat happens mostly in user level. One reason is more
friendly attitude of modern programs: instead of numeric error
codes programs contains actual error messages. Internationalization
and Unicode add to this. GUI-s demand event driven programming,
which leads to much more complicated code than earlier programs.
Sometimes programmes get lazy. I remember essay about Netscape
mail index. I fetched it from the net and my impression was that
the author was J. Zawinsky, but I can not find it on the net now.
Anyway, the essay explained tricks used to save mail index in
rather compact space ensuring fast loading. In later versions
programmers replaced custom code by generic database, leading
to something like 50 times bigger space use and slower loading
of mail index. Overal code footprint probably also increased,
as after change it included database handling code. But there
were no need to maintain previous custom code.
One reason that modern system are big and bloated is recursive
pulling of dependencies. Namely, there is tendency to delegate
work to libraries and more generally to depend on "standard"
tools. But this in turn creates pressure on libraries and
tools to cover "all" use cases and in particular to include
rarely used functionality. In turn to provide a lot of
functiality libraries and tools delegate part/most of work
to different tools. This lead to complex dependency nets
where most of functionality in total package (that is including
all dependencies) is not needed for concrete application.
> It's not just kernels and user software --
> it's also the documentation. In V7, "man cc" generates just under two
> pages of output; on my current computer, it generates over 27000 lines,
> call it 450 pages, and is thereby effectively unprintable and unreadable,
> so it is largely wasted.
>
> For V7, the entire documentation fits comfortably into two box
> files, and the entire source code is a modest pile of lineprinter output.
> Most of the commands on my current computer are undocumented and unused,
> and I have no idea at all what they do.
Hmm, on my machine '/usr/bin' contains 2547 commands. IIRC "minimal"
install give some hundreds of commands, so most commands is from
packages that I explicitely installed or their dependencies. Of course,
I remember only minority of commands, but 'man' gives me information
about many commands (my impression is that about majority, but I did
not check this). I can easily find out which package installed given
command and packages have at least short description, so even if I forget
why I installed given package usually it is easy to find out general
purpose of a command.
> Yes, I know how that "just happens", and I'm observing rather
> than complaining [I'd rather write programs, browse and send/read e-mails
> on my current computer than on the PDP-11]. But it does all give food for
> thought.
>
--
Waldek Hebisch
Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar
Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-18 04:52 +0200
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-18 16:54 +0100
Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-18 18:30 +0200
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-19 00:45 +0100
Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-19 02:44 +0200
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-20 00:47 +0100
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-20 00:43 +0000
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-20 23:58 +0100
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-21 02:59 +0000
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-08-23 00:42 +0100
Re: Algol 68 / Genie - opinions on local procedures? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-23 02:29 +0200
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-23 02:36 +0000
Economizing resource requirements (was Re: Algol 68 / Genie - opinions on local procedures?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-21 21:02 +0200
Re: Algol 68 / Genie - opinions on local procedures? antispam@fricas.org (Waldek Hebisch) - 2025-10-04 01:11 +0000
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-04 03:37 +0000
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-07 22:03 +0100
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-07 22:04 +0000
Various digressions (was Re: Algol 68 / Genie - opinions on local procedures?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 01:27 +0200
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-10 01:11 +0100
Re: Algol 68 / Genie - opinions on local procedures? Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-10 01:39 +0000
Re: Algol 68 / Genie - opinions on local procedures? Andy Walker <anw@cuboid.co.uk> - 2025-10-11 12:47 +0100
Re: Algol 68 / Genie - opinions on local procedures? antispam@fricas.org (Waldek Hebisch) - 2025-10-08 17:04 +0000
simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-26 18:42 +0000
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-27 00:28 +0000
Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-30 19:10 +0000
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-30 22:43 +0000
[OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-04 18:50 +0000
Re: [OT] NetBSD vs. Linux(-based systems) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-05 00:03 +0000
Re: [OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-07 15:55 +0000
Re: [OT] NetBSD vs. Linux(-based systems) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-09-07 21:17 +0000
Re: [OT] NetBSD vs. Linux(-based systems) cross@spitfire.i.gajendra.net (Dan Cross) - 2025-09-05 12:02 +0000
Re: [OT] NetBSD vs. Linux(-based systems) Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-07 16:30 +0000
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-27 07:53 +0200
Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-30 19:39 +0000
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-30 22:45 +0000
Re: simplicity / complexity Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-08-31 13:35 +0000
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-31 22:40 +0000
[OT] free software Ivan Shmakov <ivan@siamics.netREMOVE.invalid> - 2025-09-04 18:25 +0000
Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-08 14:03 +0000
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-08 16:21 +0200
Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-08 08:08 -0700
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-08 21:18 +0000
Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-08 14:31 -0700
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-09 00:09 +0000
Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-09 08:44 -0700
Re: simplicity / complexity Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-10-09 21:52 +0000
Re: simplicity / complexity John Ames <commodorejohn@gmail.com> - 2025-10-09 15:21 -0700
Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 00:34 +0000
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-09 03:48 +0200
Re: simplicity / complexity ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-08 14:53 +0000
Re: simplicity / complexity ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-08 15:24 +0000
Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 01:39 +0000
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-09 04:00 +0200
Re: simplicity / complexity antispam@fricas.org (Waldek Hebisch) - 2025-10-09 14:19 +0000
Re: simplicity / complexity ram@zedat.fu-berlin.de (Stefan Ram) - 2025-10-09 14:48 +0000
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-10 12:36 +0200
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-10 12:09 +0200
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 08:32 +0200
Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 08:34 +0200
csiph-web