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

Groups > comp.lang.misc > #11138 > unrolled thread

Algol 68 / Genie - opinions on local procedures?

Back to article view | Back to comp.lang.misc

Contents

  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 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 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-10-10 12:09 +0200
                            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-08-31 08:32 +0200
                  Re: simplicity / complexity Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-08-31 08:34 +0200

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

#11421

On 10/10/2025 02:39, Lawrence D’Oliveiro wrote:
[I wrote:]
>> A feature is that all those mentioned work via a USB
>> connexion [supplied with the device], irrespective of whether the Man
>> on the Clapham Omnibus would describe them as "electronic".  Is that
>> not standardisation in action?
> Do you know how many different kinds of “USB” there are?

	Is this an exam?  I have a decent-enough idea, inc the various ways
in which the versions are compatible with each other.  Standardisation is
not the same as "everything stays the same for 30 years despite the huge
changes in what domestic devices can do".  More to do with things "just
working" without someone having to write 40 million lines of code in case
I happen to install some obscure peripheral on my computer.

[...]>> But again, if information transfer is so complex, one would expect that
>> to drive standardisation rather than everyone re-inventing the wheel.
> Besides the different versions of USB previously alluded to, let me also
> mention BlueTooth, [...], 4G, 5G ...
	So which is it?  Are devices becoming standardised or are people
insisting on re-inventing the wheel?  Is this what consumers want or is
it large companies trying to lock them in to their products?  Cui bono?

-- 
Andy Walker, Nottingham.
    Andy's music pages: www.cuboid.me.uk/andy/Music
    Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Lehar

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

#11373

Andy Walker <anw@cuboid.co.uk> wrote:
> On 04/10/2025 02:11, Waldek Hebisch wrote:
>> Andy Walker <anw@cuboid.co.uk> wrote:
>>> On 20/08/2025 01:43, Lawrence D’Oliveiro wrote:
> [...]
>>>> 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. [...]
> 
>        Yes, but one would expect that to drive standardisation rather
> than bloat.  There are rather a lot of devices that I can plug into the
> mains in my home, but I don't have to install hundreds or thousands of
> different types of socket.

Note that a lot of companies do not want to compete in commodity
market.  They want to collect "extraordinary added value" by
innovating.  But most innovation is either in drivers or need
driver support.  So companies have motivation to limit use of
drivers to their devices.  I other words they _want_ to be
incompatible with other devices.  Of course, this is mitigated
by total developement cost.  But there is a bunch of gratitious
incompatibilites.  There are independently developed products,
again developement is frequently secret and when devices enter
market they need separate drivers.

>> 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.
>        I would take issue with some of the historical aspects, but it
> would take us on a long detour.  Just one comment:  we've had virtual
> memory since 1959 [Atlas].

1) You enough real memory to make virtual memory really effective.
   There are things that you really want to keep in real RAM.
2) Fact that some big or innovative machine allows to do thing
   better is not enough.  Programmers typically work with available
   hardware, so hardware/software support must be popular enough
   to matter for programmers practice.

>> 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.
> 
>        The systems I've used have always used actual error messages!

Well, first trick to fit program into available memory that I have
seen was to eliminate textual messages, debugging support etc.
That was especially in case of small systems without hard drive
(so trick with storing messages on the disk was not possible).

I already mentioned overlays, but let me add that they frequently
were combined with multipass approach.  Having less passes gives
better speed as long as you have enough memory.

Another trick used bytecode interpreters.  Interpreter itself can
be quite small and well-chosen bytecode typically is much smaller
than machine code.  But execution needs more CPU time.  With
careful tuning and rewriting critical parts in machine code
one can get reasonable result, at cost of approproiate programmer
effort.

> [...]
>> 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.
> 
>        Yes, but that's the sort of pressure that needs to be
> resisted;  and isn't,

Well, I am trying to limit dependencies for my software, which
may mean writing my own function for some purpose instead of
using a library.  OTOH if shared library is loaded into RAM
by another user, than runtime cost of additional user is
rather low.  And writing my function means extra source code.
So that is tricky balance.

Concerning rarely used functionality in libraries, alone I do
not think it is big problem.  I mean, having such code in
library means that sharing at source code level is possible
so it is likely to lead to decrease in total amount of
source code needed to implement functionality of modern
systems.

And I am trying to see things in the context.  People have
a lot of computing needs, some really important, some of
lower priority.  Computing hardware is much cheaper than it
was in the past, so main barrier to satifying "all" computing
needs is cost of creating software.  Especially for less
common needs it makes sense to use rather inefficient approaches
because doing things "properly" would require too much programming
effort.  So, instead we try to maximize amount of functionalty
given avaliable programmer effort and available computing
resources.  Which frequently mean that we are happy that
a program works at all and not bothered to much by bloat.

Let me add that personally I am probably much less tolerant
to bloat than average.  But when I use open source software,
should I complian that it uses more resources than strictly
neccessary?  I certainly can not create myself all that
software (or pay for its creation).

> [...]
>> 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.
> 
>        I have 2580 in my "/usr/bin".  That is almost all from the
> "medium (recommended)" installation;  a handful of others have been
> added when I've found something missing (I'd guess perhaps 10).  Of
> those I've actually used just 64!  [Plus 26 in "$HOME/bin".]  I
> checked a random sample of those 2580;  more than 2/3 I have no
> idea from the name what they are for [yes, I know I can find out],
> and I'm an experienced Unix user with much more CS knowledge than
> the average punter.  If I were to read an introductory book on
> Linux, I doubt whether many more than those 64 would be mentioned,
> so I wouldn't even be pointed at the "average" command.

I use debian 12.  "Bigger" install options tend to pull in GUI
stuff that I do not want.  I use LXDE and prefer to avoid KDE
or Gnome.  Of course there are Gnome/KDE programs that I use
and that pull corresponding shared libraries, but AFAICS I get
less Gnome and KDE programs that I would get choosing it as a
desktop environment.  On other machines I did minimal (non-GUI)
install and it was much smaller.  On a small machine I did GUI
install, but installed only limited number of packages.  On
that machine I have 1274 programs in /usr/bin.  So majority
of programs on my main machine goes beyond "small" GUI install.

Note: I do not remember if I did minimal install first and
then added GOI or choos GUI option during initial install.
The point is that this is GUI that I actually use, most commands
is invoked from menus but I start some GUI things from command
line.

64 commands that you actually used looks very low.  I am too lazy
to count commands that I use.  But I have cross-developement
toolchains for AVR (27 commands), ARM (28 commands), RISC-V
(25 commands).  I have both normal x86_64 toolchain and
support to x32 variant (28 commands).  x86_64 toolchain installs
things under duplicate name, 74 commands have prefix
'x86_64-linux-gnu-' and each probably have unprefixed version.
So only counting part of development commands that I use
I have about 256 commands that I am reasonably likely to use
(some commands come under multiple names, normally I would
use only one name, but I may use other names say for ease of forming
names in build scripts).  Note that by default Debian installs
essentially no developement support (Debian install 'cpp' for
use by some other programs), so those are present because I
need them.

Also, note that stuff that used to be in '/bin' is now in
'/usr/bin'.  That is tens of simple command that any serious
Unix user is likely to use.

Of course, if you take an "average user", then such person may
be unaware of existence of command line so number of commands
that such person explicitely uses would be 0.  Even some
developers apparently depend on GUI tools and are lost when
they need say to write a Makefile.  But a lot of behind the
scene machinery (and some commands) exists to allow such user
productively use computers.

-- 
                              Waldek Hebisch

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

#11170 — simplicity / complexity

>>>>> On 2025-08-19, Janis Papanagnou wrote:
>>>>> On 19.08.2025 01:45, Andy Walker wrote:

 >>>> If you're worried about 15%, that will be more than compensated
 >>>> for by your next computer!

 >>> Actually I'm very conservative concerning computers; mine is 15+
 >>> years old, and although I "recently" thought about getting an
 >>> update here it's not my priority. ;-)

 >> Ah.  I thought I was bad, keeping computers 10 years or so!  I got
 >> a new one a couple of years back, and the difference in speed and
 >> storage was just ridiculous.

	Reading http://en.wikipedia.org/wiki/E-waste , I'm inclined to
	think that keeping computers for a decade might be not so bad
	a thing after all.

 > Well, used software tools (and their updates) required me to at
 > least upgrade memory!  (That's actually one point that annoys me
 > in "modern" software development; rarely anyone seems to care
 > economizing resource requirements.)

	I doubt it's so much lack of care as it is simply being not a
	priority.  Still, all the more reason to direct attention to
	the cases where such care /is/ given.  Thankfully, the problem
	/is/ a known one (say, [1]), and IME, there still /are/ lean
	programs to choose from.

	By the by, I've been looking for "simple" self-hosting compilers
	recently - something with source that a semi-dedicated person
	can read through in reasonable time.  What I've found so far is
	Pygmy Forth (naturally, I guess) and the T3X family of languages
	[2].  Are there perhaps other such compilers worthy of mention?

[1] http://spectrum.ieee.org/lean-software-development
[2] http://pygmy.utoh.org/pygmyforth.html
[3] http://t3x.org/t3x/

	I'll also try to address here specific points raised elsewhere
	in this thread, particularly news:1087qgv$14ret$1@dont-email.me .

	First, the 4e7 lines of Linux code is somewhat unfair a measure.
	On my system, less than 5% of individual modules built from the
	Linux source are loaded right now:

$ lsmod | wc -l 
175
$ find /lib/modules/6.1.0-37-amd64/ -xdev -type f -name \*.ko | wc -l 
4024
$ 

	That value would of course vary from system to system, but I'd
	think it's safe to say that in at least 90% of all deployments,
	less than 10% of Linux code will be loaded at any given time.

	For those who are looking for a system with more "comprehensible"
	sources, I would recommend NetBSD.  And if anything, I personally
	find its list of supported platforms, http://netbsd.org/ports/ ,
	fairly impressive.

	Don't get me wrong: NetBSD won't fit for every use case Linux-based
	systems cover - the complexity of the Linux kernel isn't there
	for nothing - but just in case you /can/ live with a "limited"
	OS (say, one that doesn't support Docker), thanks to NetBSD, you
	/do/ have that option.

	With regards to applications, while binary distributions tend to
	opt to have the most "fully functional" built of any given
	package - from whence come lots of dependencies - a source-based
	one allows /you/ to choose what you need.  And pkgsrc for NetBSD
	is such a distribution.  Gentoo is a Linux-based distribution
	along the same lines.

	As to websites and JS libraries, for the past 25 years I've been
	using as my primary one a browser, Lynx, that never had support
	for JS, and likely never will have.  IME, an /awful lot/ of
	websites are usable and useful entirely without JS.  For those
	interested, I've recently made several comments in defense of
	"JS-free" web and web browsers, such as [4, 5, 6].

[4] news:ID351XcOrll9pkb7@violet.siamics.net
[5] news:6brTAD5tWnddeHXd@violet.siamics.net
[6] news:ii6tqUtTe0Vi-Fnh@violet.siamics.net

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

#11173 — Re: simplicity / complexity

On Tue, 26 Aug 2025 18:42:05 +0000, Ivan Shmakov wrote:

> First, the 4e7 lines of Linux code is somewhat unfair a measure. On
> my system, less than 5% of individual modules built from the Linux
> source are loaded right now ...

Greg Kroah-Hartman is reported to have said that a typical
workstation/server Linux kernel build only needs about 1½ million
lines of source code. A more complex build, like an Android kernel,
needs something like 3× that.

> For those who are looking for a system with more "comprehensible"
> sources, I would recommend NetBSD. And if anything, I personally
> find its list of supported platforms, http://netbsd.org/ports/ ,
> fairly impressive.

Bit misleading, though. Note it counts “Xen” (a Linux-based
hypervisor) as a separate platform. Also, look at all the different
68k, MIPS, ARM and PowerPC-based machines that are individually
listed.

Linux counts platform support based solely on CPU architecture (not
surprising, since it’s just a kernel, not the userland as well). It
covers all those CPUs listed (except maybe VAX), and a bunch of others
as well.

Each directory here <https://github.com/torvalds/linux/tree/master/arch>
represents a separate supported architecture. Note extras like arm64,
riscv, loongarch and s390.

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

#11187 — Re: simplicity / complexity

>>>>> On 2025-08-27, Lawrence D'Oliveiro wrote:
>>>>> On Tue, 26 Aug 2025 18:42:05 +0000, Ivan Shmakov wrote:

 >> For those who are looking for a system with more "comprehensible"
 >> sources, I would recommend NetBSD.  And if anything, I personally
 >> find its list of supported platforms, http://netbsd.org/ports/ ,
 >> fairly impressive.

 > Bit misleading, though.  Note it counts "Xen" (a Linux-based
 > hypervisor) as a separate platform.

	What do you mean by "Linux-based"?  NetBSD supports running
	as both Xen domU (unprivileged) /and/ dom0 (privileged.)
	AIUI, it's possible to run Linux domUs when NetBSD is dom0,
	and vice versa.

 > Also, look at all the different 68k, MIPS, ARM and PowerPC-based
 > machines that are individually listed.

 > Linux counts platform support based solely on CPU architecture (not
 > surprising, since it's just a kernel, not the userland as well).

	There's a "Ports by CPU architecture" section down the NetBSD
	ports page; it lists 16 individual CPU architectures.

	My point was that GNU/Linux distributions typically support
	less, and so do other BSDs (IIRC.)  For instance, [1] lists 8:

 1> Architectures: all amd64 arm64 armel armhf i386 ppc64el riscv64 s390x

[1] http://cdn-fastly.deb.debian.org_debian_dists_trixie_InRelease

	(And I'm pretty certain I saw ones that only support one or two.)

	The way I see it, it's the /kernel/ that it takes the most
	effort to port to a new platform - as it's where the support
	for peripherals lives, including platform-specific ones.

	No idea why Debian doesn't support other architectures supported
	by Linux.  I'm going to guess it's lack of volunteers.

 > It covers all those CPUs listed (except maybe VAX), and a bunch of
 > others as well.

 > Each directory here <https://github.com/torvalds/linux/tree/master/arch>
 > represents a separate supported architecture. Note extras like arm64,

	Getting actual data out of Microsoft Github pages is a bit more
	involved than I'd prefer.  Still:

$ curl -- https://github.com/torvalds/linux/tree/master/arch \
      | pcregrep -ao1 -- "\"path\":\"arch/([/0-9a-z_.-]+)\"" | nl -ba 
     1	alpha
     2	arc
     3	arm
     4	arm64
     5	csky
     6	hexagon
     7	loongarch
     8	m68k
     9	microblaze
    10	mips
    11	nios2
    12	openrisc
    13	parisc
    14	powerpc
    15	riscv
    16	s390
    17	sh
    18	sparc
    19	um
    20	x86
    21	xtensa
    22	.gitignore
$ 

	So, yes, I guess it does beat NetBSD in that respect.  But I
	still think that if you're interested in understanding how your
	OS works - at the source code level - you'd be better with
	NetBSD than with a Linux-based OS.  (Not /quite/ a priority
	for me personally, TBH, but I appreciate it being an option.)

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

#11189 — Re: simplicity / complexity

On Sat, 30 Aug 2025 19:10:42 +0000, Ivan Shmakov wrote:

>> On Wed, 27 Aug 2025 00:28:20 -0000 (UTC), Lawrence D’Oliveiro
>> wrote:
>
>> Bit misleading, though.  Note it counts "Xen" (a Linux-based
>> hypervisor) as a separate platform.
>
> What do you mean by "Linux-based"?

I mean that Xen runs an actual Linux kernel in the hypervisor, and
supports regular Linux distros as guests -- they don’t need to be
modified to specially support Xen, or any other hypervisor. It’s
Linux above, and Linux below -- Linux at every layer.

> NetBSD supports running as both Xen domU (unprivileged) /and/ dom0
> (privileged.)

Linux doesn’t count these as separate platforms. They’re just
considered a standard part of regular platform support.

>> Linux counts platform support based solely on CPU architecture (not
>> surprising, since it's just a kernel, not the userland as well).
>
> There's a "Ports by CPU architecture" section down the NetBSD
> ports page; it lists 16 individual CPU architectures.

That’s not as many as Linux.

> My point was that GNU/Linux distributions typically support
> less ...

But that’s an issue with the various distributions, not with the Linux
kernel itself. In the BSD world, there is no separate of “kernel” from
“distribution”. That makes things less flexible than the Linux world.

For example, while base Debian itself may support something under a
dozen architectures, there are offshoots of Debian that cover others.

> The way I see it, it's the /kernel/ that it takes the most
> effort to port to a new platform - as it's where the support
> for peripherals lives, including platform-specific ones.

Given that the Linux kernel supports more of these different platforms
than any BSD can manage, I think you’re just reinforcing my point.

> But I still think that if you're interested in understanding how
> your OS works - at the source code level - you'd be better with
> NetBSD than with a Linux-based OS.

Linux separates the kernel from the userland. That makes things
simpler than running everything together, as the BSDs do.

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

#11220 — [OT] NetBSD vs. Linux(-based systems)

>>>>> On 2025-08-30, Lawrence D'Oliveiro wrote:
>>>>> On Sat, 30 Aug 2025 19:10:42 +0000, Ivan Shmakov wrote:
>>>>> On Wed, 27 Aug 2025 00:28:20 -0000 (UTC), Lawrence D'Oliveiro wrote:

	I think it makes sense to restate the point I'm arguing for in
	this subthread (see news:y2C3FavstjxdDZ-_@violet.siamics.net ):

 IS> For those who are looking for a system with more "comprehensible"
 IS> sources, I would recommend NetBSD.  And if anything, I personally
 IS> find its list of supported platforms, http://netbsd.org/ports/ ,
 IS> fairly impressive.

 IS> Don't get me wrong: NetBSD won't fit for every use case Linux-based
 IS> systems cover - the complexity of the Linux kernel isn't there
 IS> for nothing - but just in case you /can/ live with a "limited"
 IS> OS (say, one that doesn't support Docker), thanks to NetBSD, you
 IS> /do/ have that option.

	To stress it out, it wasn't my intent to compare NetBSD as
	a whole to the Linux kernel (as that's just silly.)  Neither
	was it my intent to compare the NetBSD kernel to Linux, as:
	a. I don't have any use cases for a /kernel/ outside of an OS
	distribution; and b. I mostly use Linux-based systems myself.
	(And hence arguing that way would be a case of failing to
	practice what I preach.)

	All the same, should I ever encounter a problem that requires
	kernel-mode coding, NetBSD would be at the top of my list of
	options - because of code readability.

 >>> Bit misleading, though.  Note it counts "Xen" (a Linux-based
 >>> hypervisor) as a separate platform.

 >> What do you mean by "Linux-based"?

 > I mean that Xen runs an actual Linux kernel in the hypervisor,
 > and supports regular Linux distros as guests -- they don't need to
 > be modified to specially support Xen, or any other hypervisor.

	It's been well over a decade since I've last used Xen, so I'm
	going more by http://en.wikipedia.org/wiki/Xen than experience.

	But just to be sure, I've checked the sources [1], and while
	I do see portions of Linux code reused here and there - such as,
	say, [2] below - I'd hesitate to call Xen at large "Linux-based."
	If anything, there's way more of Linux in the GNU Mach microkernel
	(consider the linux/src/drivers subtree in [3], for instance)
	than in the Xen hypervisor.  (And I don't recall GNU Mach being
	called "Linux-based.")

	To note is that there seem to be no mention in CHANGELOG.md of
	anything suggesting that Xen uses Linux as its upstream project.

 2>  * common/notifier.c
 2>  *
 2>  * Routines to manage notifier chains for passing status changes to any
 2>  * interested routines.
 2>  *
 2>  * Original code from Linux kernel 2.6.27 (Alan Cox [...])

[1] http://downloads.xenproject.org/release/xen/4.20.1/xen-4.20.1.tar.gz
[2] xen-4.20.1/xen/common/notifier.c
[3] git://git.sv.gnu.org/hurd/gnumach.git rev. 8d456cd9e417 from 2025-09-03

 > It's Linux above, and Linux below -- Linux at every layer.

	Sure, if you want to run it that way.  You can also run Xen
	with NetBSD at every layer, or, apparently, OpenSolaris.

	A GNU/Linux distribution AFAICR needs to provide Xen-capable
	kernel for it to be usable as dom0 - as well as Xen user-mode
	tools.  Niche / lightweight distributions might omit such support.
	(There're a few build-time options related to Xen in Linux.)

	Also, Xen supports both hardware-assisted virtualization /and/
	paravirtualization.  On x86-32, the former is not available, so
	the Linux build /must/ support paravirtualization in order to be
	usable with Xen, dom0 or domU.

	When hardware-assisted virtualization /is/ available, the things
	certainly get easier: pretty much anything that can run under,
	say, Qemu, can be run under Xen HVM.  The performance may suffer,
	though, should your domU system happen to lack virtio drivers and
	should thus need to resort to using emulated peripherals instead.

 >> NetBSD supports running as both Xen domU (unprivileged) /and/
 >> dom0 (privileged.)

 > Linux doesn't count these as separate platforms.  They're just
 > considered a standard part of regular platform support.

	Which means one needs to be careful when comparing architecture
	support between different kernels.

 >> My point was that GNU/Linux distributions typically support less

 > But that's an issue with the various distributions, not with the
 > Linux kernel itself.

	True.  That, however, doesn't mean you can use Linux /by itself/
	outside of a distribution.  (Unless, of course, you're looking
	for a kernel for a new distribution, but I doubt that undermines
	my point.)  So architecture support /you/ will have /will/ be
	limited by the distribution you choose, regardless of what Linux
	itself might offer.

 > In the BSD world, there is no separate of "kernel" from "distribution".
 > That makes things less flexible than the Linux world.

	That's debatable.  Debian for a while had a kFreeBSD port (with
	a variant of the FreeBSD kernel separate from FreeBSD proper), and
	from what I recall, it was discontinued due to lack of volunteers,
	not lack of flexibility.

 > For example, while base Debian itself may support something under a
 > dozen architectures, there are offshoots of Debian that cover others.

	How is this observation helpful?

	Suppose someone asks, "what OS would you recommend for running
	on loongarch?" and the best answer we here on Usenet can give
	is along the lines of "NetBSD won't work, but there're dozens
	of Debian offshoots around - be sure to check them all, as one
	might happen to support it."  Really?

	If you know of Debian offshoots that support architectures
	that Debian itself doesn't, could you please list them here?
	Or, if there's already a list somewhere, share a pointer.

 >> The way I see it, it's the /kernel/ that it takes the most effort
 >> to port to a new platform - as it's where the support for peripherals
 >> lives, including platform-specific ones.

 > Given that the Linux kernel supports more of these different
 > platforms than any BSD can manage, I think you're just reinforcing
 > my point.

	Certainly - if your point is that way more effort went into
	Linux over the past two to three decades than in any of BSDs.
	(And perhaps into /all/ of free BSDs combined, I'd guess.)

 >> But I still think that if you're interested in understanding how
 >> your OS works - at the source code level - you'd be better with
 >> NetBSD than with a Linux-based OS.

 > Linux separates the kernel from the userland.  That makes things
 > simpler than running everything together, as the BSDs do.

	I fail to see why developing the kernel and an OS based on it
	as subprojects to one "umbrella" project would in any way hinder
	code readability.

	Just in case it somehow matters, there're separate tarballs under
	rsync://rsync.netbsd.org/NetBSD/NetBSD-10.1/source/sets/ for the
	kernel (syssrc.tgz) and userland (src, gnusrc, sharesrc, xsrc.)

	That said, I've last tinkered with Linux around the days of
	2.0.36 (IIRC), and I don't recall reading any Linux sources
	newer than version 4.  If you have experience patching newer
	Linux kernels, and in particular if you find the code easy to
	follow, - please share your observations.

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

#11221 — Re: [OT] NetBSD vs. Linux(-based systems)

On Thu, 04 Sep 2025 18:50:29 +0000, Ivan Shmakov wrote:

> - I'd hesitate to call Xen at large "Linux-based." If anything,
> there's way more of Linux in the GNU Mach microkernel (consider the
> linux/src/drivers subtree in [3], for instance) than in the Xen
> hypervisor.

Call it what you like, the fact is, Linux supports it without having
to list it as a separate platform.

You could argue equally well that NetBSD is not “BSD” any more,
because it has diverged too far from the original BSD kernel.

> That, however, doesn't mean you can use Linux /by itself/ outside of
> a distribution.

How do you think distributions get created in the first place?

<https://linuxfromscratch.org/>

> Suppose someone asks, "what OS would you recommend for running on
> loongarch?" and the best answer we here on Usenet can give is

<https://distrowatch.com/search.php?ostype=All&category=All&origin=All&basedon=All&notbasedon=None&desktop=All&architecture=loongarch64&package=All&rolling=All&isosize=All&netinstall=All&language=All&defaultinit=All&status=Active#simpleresults>

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

#11228 — Re: [OT] NetBSD vs. Linux(-based systems)

>>>>> On 2025-09-05, Lawrence D'Oliveiro wrote:
>>>>> On Thu, 04 Sep 2025 18:50:29 +0000, Ivan Shmakov wrote:

 >> I'd hesitate to call Xen at large "Linux-based."  If anything,
 >> there's way more of Linux in the GNU Mach microkernel (consider
 >> the linux/src/drivers subtree in [3], for instance) than in the
 >> Xen hypervisor.

 > Call it what you like, the fact is, Linux supports it without
 > having to list it as a separate platform.

	I can't say I can quite grasp the importance of doing it one
	way or another, but well, I've been loosely working on my own
	"Debian offshoot" over the past few years, and should it ever
	come to a release, I'll be sure to test it with Xen and then
	list "Xen on amd64" alongside "amd64 on bare metal" in its list
	of supported platforms - NetBSD-style.

 > You could argue equally well that NetBSD is not "BSD" any more,
 > because it has diverged too far from the original BSD kernel.

	That's a good point, actually: as originally defined, "BSD" meant
	"Berkeley Software Distribution," and given that little (if any)
	work on NetBSD is (AIUI) currently being done at UCB, I'd say
	that yes, NetBSD is not "BSD" - and likely never have been.

	(Similarly, I find claims that "Debian is a free Unix" to be
	misleading: "GNU's Not Unix" is right on the cover, after all.)

	NetBSD is a descendant of 386BSD (as, AIUI, are all current
	"BSDs"), itself a descendant of 4.3BSD, so there /is/ a kind
	of continuity.  (And likely bits of actual 4.3BSD code within
	NetBSD sources.)  No idea if it's of much importance to anyone
	but OS historians.

 >> That, however, doesn't mean you can use Linux /by itself/ outside
 >> of a distribution.  (Unless, of course, you're looking for a kernel
 >> for  a new distribution, but I doubt that undermines my point.)

 > How do you think distributions get created in the first place?

 > <https://linuxfromscratch.org/>

	Like I've said, I doubt that undermines my point: you /still/
	choose among distributions rather than kernels, even if one
	(or more) of those distributions is of your own creation.

	When two decades ago I've put together my own "distribution"
	(I've never actually /distributed/ it, hence the quotes), the
	only CPU architecture it supported was "i386" - as that was the
	only one that I've had at hand and could test it on.  How many
	others Linux supported at the time, I've had no idea - nor any
	reason to look into: they simply were out of my reach - and thus
	my concern - at the time.

	The aforementioned Debian derivative I'm working on currently
	only supports amd64, though I hope to add riscv64 and (or) arm64
	support eventually.  From where I stand, adding support for
	anything beyond that (and especially architectures that aren't
	in Debian, and for which I thus cannot reuse Debian packages)
	is too much effort for too uncertain a gain.

	(Reportedly "i386" support is important for running Steam on
	Debian, but guess what?  I use GOG.)

	Sure, it'd be nice to have a Debian derivative to run on my i586
	boxes (not supported after Jessie), but that's lots of effort,
	too - and then there's NetBSD that's already "486DX or better."

	With the above in mind, well, I'm willing to bet that if you
	ever put together your own distribution, it won't support every
	architecture Linux itself claims to support, either.

 >> Suppose someone asks, "what OS would you recommend for running on
 >> loongarch?" and the best answer we here on Usenet can give is

 > <https://distrowatch.com/search.php?ostype=All&[...]>

	... Or, in other words: "don't ask for recommendations here on
	Usenet, ask a website instead."  What Usenet is even here for,
	then?  Rants?

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

#11230 — Re: [OT] NetBSD vs. Linux(-based systems)

On Sun, 07 Sep 2025 15:55:43 +0000, Ivan Shmakov wrote:

> On Fri, 5 Sep 2025 00:03:17 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>
>> On Thu, 04 Sep 2025 18:50:29 +0000, Ivan Shmakov wrote:
>>
>>> I'd hesitate to call Xen at large "Linux-based."
>
>> Call it what you like, the fact is, Linux supports it without
>> having to list it as a separate platform.
>
> I can't say I can quite grasp the importance of doing it one way or
> another ...

The fact that NetBSD has to list it as a separate platform to get its
count up.

Also:

    [09:10 xcp-ng-126 ~]# uname -a
    Linux xcp-ng-126 4.19.0+1 #1 SMP Tue May 6 15:24:43 CEST 2025 x86_64 x86_64 x86_64 GNU/Linux

> ... you /still/ choose among distributions rather than kernels ...

The fact that all Linux distros share essentially the same kernel
makes it much easier to interoperate and also switch between them:
“distro-hopping” is a common activity in the Linux world, it’s not
something that can be encouraged in the BSD world.

> ... Or, in other words: "don't ask for recommendations here on
> Usenet, ask a website instead."

You asked for information, clearly in the expectation that it would
not be forthcoming. I gave you the information, now you find another
reason to complain?

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

#11224 — Re: [OT] NetBSD vs. Linux(-based systems)

In article <KKx97WvtTkldzxgb@violet.siamics.net>,
Ivan Shmakov  <ivan@siamics.netREMOVE.invalid> wrote:
>>>>>> On 2025-08-30, Lawrence D'Oliveiro wrote:

FYI, you are arguing with a known troll.  It is unlikely to turn
into a productive exercise, so caveat emptor.

> [snip]
> > I mean that Xen runs an actual Linux kernel in the hypervisor,
> > and supports regular Linux distros as guests -- they don't need to
> > be modified to specially support Xen, or any other hypervisor.
>
>	It's been well over a decade since I've last used Xen, so I'm
>	going more by http://en.wikipedia.org/wiki/Xen than experience.
>
>	But just to be sure, I've checked the sources [1], and while
>	I do see portions of Linux code reused here and there - such as,
>	say, [2] below - I'd hesitate to call Xen at large "Linux-based."
>	If anything, there's way more of Linux in the GNU Mach microkernel
>	(consider the linux/src/drivers subtree in [3], for instance)
>	than in the Xen hypervisor.  (And I don't recall GNU Mach being
>	called "Linux-based.")
>
>	To note is that there seem to be no mention in CHANGELOG.md of
>	anything suggesting that Xen uses Linux as its upstream project.

This is basically correct.  Xen falls into the broad category
known as "Type-1" hypervisors: meaning that Xen controls runs
directly on the bare metal outside of the context of an existing
OS (versus, say, KVM, Bhyve, etc).  It is true that Xen was
centered on Linux initially, and pulled in a lot of the code; I
think it's fair to say that early versions largely started with
(and in many ways were based on) the Linux kernel, but it has
clearly gone its own way.

In the Type-1 model, you still need some software component that
lets you do stuff like configure virtual machines, provide
device models to guests, and so on.  It's common to provide a
specially blessed VM instance (Dom0 in Xen; a "root VM" in
Hyper-V) to do this.

> 2>  * common/notifier.c
> 2>  *
> 2>  * Routines to manage notifier chains for passing status changes to any
> 2>  * interested routines.
> 2>  *
> 2>  * Original code from Linux kernel 2.6.27 (Alan Cox [...])
>
>[1] http://downloads.xenproject.org/release/xen/4.20.1/xen-4.20.1.tar.gz
>[2] xen-4.20.1/xen/common/notifier.c
>[3] git://git.sv.gnu.org/hurd/gnumach.git rev. 8d456cd9e417 from 2025-09-03
>
> > It's Linux above, and Linux below -- Linux at every layer.
>
>	Sure, if you want to run it that way.  You can also run Xen
>	with NetBSD at every layer, or, apparently, OpenSolaris.
>
>	A GNU/Linux distribution AFAICR needs to provide Xen-capable
>	kernel for it to be usable as dom0 - as well as Xen user-mode
>	tools.  Niche / lightweight distributions might omit such support.
>	(There're a few build-time options related to Xen in Linux.)
>
>	Also, Xen supports both hardware-assisted virtualization /and/
>	paravirtualization.  On x86-32, the former is not available, so
>	the Linux build /must/ support paravirtualization in order to be
>	usable with Xen, dom0 or domU.
>
>	When hardware-assisted virtualization /is/ available, the things
>	certainly get easier: pretty much anything that can run under,
>	say, Qemu, can be run under Xen HVM.  The performance may suffer,
>	though, should your domU system happen to lack virtio drivers and
>	should thus need to resort to using emulated peripherals instead.

Yes.  With Xen, you've got the Xen VMM running on the bare metal
and then any OS capable of supporting Xen's Dom0 requirements
running as Dom0, and essentially any OS running as a DomU guest.

So to summarize, you've got a hypervisor that descended from an
old version of Linux, but was heavily modified, running a gaggle
of other systems, none of which necessarily needs to be Linux.

> >> NetBSD supports running as both Xen domU (unprivileged) /and/
> >> dom0 (privileged.)
>
> > Linux doesn't count these as separate platforms.  They're just
> > considered a standard part of regular platform support.
>
>	Which means one needs to be careful when comparing architecture
>	support between different kernels.

I gathered your point was that neither Dom0 nor DomU _had_ to be
Linux, and that's true.  Note that the troll likes to subtlely
change the point that he's arguing.

> >> My point was that GNU/Linux distributions typically support less
>
> > But that's an issue with the various distributions, not with the
> > Linux kernel itself.
>
>	True.  That, however, doesn't mean you can use Linux /by itself/
>	outside of a distribution.  (Unless, of course, you're looking
>	for a kernel for a new distribution, but I doubt that undermines
>	my point.)  So architecture support /you/ will have /will/ be
>	limited by the distribution you choose, regardless of what Linux
>	itself might offer.
>
> > In the BSD world, there is no separate of "kernel" from "distribution".
> > That makes things less flexible than the Linux world.
>
>	That's debatable.  Debian for a while had a kFreeBSD port (with
>	a variant of the FreeBSD kernel separate from FreeBSD proper), and
>	from what I recall, it was discontinued due to lack of volunteers,
>	not lack of flexibility.
>
> > For example, while base Debian itself may support something under a
> > dozen architectures, there are offshoots of Debian that cover others.
>
>	How is this observation helpful?
>
>	Suppose someone asks, "what OS would you recommend for running
>	on loongarch?" and the best answer we here on Usenet can give
>	is along the lines of "NetBSD won't work, but there're dozens
>	of Debian offshoots around - be sure to check them all, as one
>	might happen to support it."  Really?
>
>	If you know of Debian offshoots that support architectures
>	that Debian itself doesn't, could you please list them here?
>	Or, if there's already a list somewhere, share a pointer.
>
> >> The way I see it, it's the /kernel/ that it takes the most effort
> >> to port to a new platform - as it's where the support for peripherals
> >> lives, including platform-specific ones.
>
> > Given that the Linux kernel supports more of these different
> > platforms than any BSD can manage, I think you're just reinforcing
> > my point.
>
>	Certainly - if your point is that way more effort went into
>	Linux over the past two to three decades than in any of BSDs.
>	(And perhaps into /all/ of free BSDs combined, I'd guess.)
>
> >> But I still think that if you're interested in understanding how
> >> your OS works - at the source code level - you'd be better with
> >> NetBSD than with a Linux-based OS.
>
> > Linux separates the kernel from the userland.  That makes things
> > simpler than running everything together, as the BSDs do.
>
>	I fail to see why developing the kernel and an OS based on it
>	as subprojects to one "umbrella" project would in any way hinder
>	code readability.
>
>	Just in case it somehow matters, there're separate tarballs under
>	rsync://rsync.netbsd.org/NetBSD/NetBSD-10.1/source/sets/ for the
>	kernel (syssrc.tgz) and userland (src, gnusrc, sharesrc, xsrc.)
>
>	That said, I've last tinkered with Linux around the days of
>	2.0.36 (IIRC), and I don't recall reading any Linux sources
>	newer than version 4.  If you have experience patching newer
>	Linux kernels, and in particular if you find the code easy to
>	follow, - please share your observations.

He doesn't.

	- Dan C.

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

#11229 — Re: [OT] NetBSD vs. Linux(-based systems)

>>>>> On 2025-09-05, Dan Cross wrote:
>>>>> In article <KKx97WvtTkldzxgb@violet.siamics.net>, Ivan Shmakov wrote:
>>>>> On 2025-08-30, Lawrence D'Oliveiro wrote:

 > FYI, you are arguing with a known troll.  It is unlikely to turn
 > into a productive exercise, so caveat emptor.

	I'm inclined to define productive public discussion as one
	that's informative and interesting to read.  Given that I've
	actually ended up learning a couple of things along the way,
	I'd say it /was/ productive, in a way.

	With no "views" and "likes" counts here on Usenet, I have no way
	of measuring how interesting the subthread was to others (being
	ill-suited for the group as it is), so I kinda hope for the best.

 >> When hardware-assisted virtualization /is/ available, the things
 >> certainly get easier: pretty much anything that can run under,
 >> say, Qemu, can be run under Xen HVM.  The performance may suffer,
 >> though, should your domU system happen to lack virtio drivers and
 >> should thus need to resort to using emulated peripherals instead.

 > Yes.  With Xen, you've got the Xen VMM running on the bare metal and
 > then any OS capable of supporting Xen's Dom0 requirements running as
 > Dom0, and essentially any OS running as a DomU guest.

 > So to summarize, you've got a hypervisor that descended from an
 > old version of Linux, but was heavily modified, running a gaggle
 > of other systems, none of which necessarily needs to be Linux.

	Glad to know I wasn't too off the mark in this case.

 >>> Linux doesn't count these as separate platforms.  They're just
 >>> considered a standard part of regular platform support.

 >> Which means one needs to be careful when comparing architecture
 >> support between different kernels.

 > I gathered your point was that neither Dom0 nor DomU _had_ to be
 > Linux, and that's true.

	More to the point here is that my opponent took offense at
	http://netbsd.org/ports/ listing "Xen" as one of the supported
	"platforms" - apparently for the sole reason that Linux does
	it differently.

 > Note that the troll likes to subtlely change the point that he's
 > arguing.

	Well, in a properly set up public debate, there's ought to be
	a prior agreement on who's arguing what.  This is Usenet, however,
	so we all figure out what points we do and do not want to argue
	along the way.  I doubt I can rightfully blame a person for not
	sharing my preferences about on what to argue about - especially
	as I don't pay them for having an argument with me.

 >> That said, I've last tinkered with Linux around the days of 2.0.36
 >> (IIRC), and I don't recall reading any Linux sources newer than
 >> version 4.  If you have experience patching newer Linux kernels, and
 >> in particular if you find the code easy to follow, - please share.

 > He doesn't.

	That's what I suspect as well.  I'd still be delighted to be
	proven wrong.

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

#11174 — Re: simplicity / complexity

On 26.08.2025 20:42, Ivan Shmakov wrote:
>>>>>> On 2025-08-19, Janis Papanagnou wrote:
> 
>  > Well, used software tools (and their updates) required me to at
>  > least upgrade memory!  (That's actually one point that annoys me
>  > in "modern" software development; rarely anyone seems to care
>  > economizing resource requirements.)
> 
> 	I doubt it's so much lack of care as it is simply being not a
> 	priority.  [...]

But those are depending each other. - Quoting from your link below...

Wirth:
    “Time pressure is probably the foremost reason behind the emergence
 of bulky software. The time pressure that designers endure discourages
 careful planning. It also discourages improving acceptable solutions;
 instead, it encourages quickly conceived software additions and
 corrections. Time pressure gradually corrupts an engineer’s standard
 of quality and perfection. It has a detrimental effect on people as
 well as products.”

And, to be yet more clear; I also think it's [widely] just ignorance!
(The mere existence of the article you quoted below is per se already
a strong sign for that. But also other experiences, like talks with
many IT-folks of various age and background reinforced my opinion on
that.)

> [...]
> 
> [1] http://spectrum.ieee.org/lean-software-development

Thanks for the link; worth reading.

(And also learned BTW that I missed that N. Wirth deceased last year.)

> [...]
> 
> 	As to websites and JS libraries, for the past 25 years I've been
> 	using as my primary one a browser, Lynx, that never had support
> 	for JS, and likely never will have.  IME, an /awful lot/ of
> 	websites are usable and useful entirely without JS.  [...]

Lynx. This is great. - I recall that in the 1990's I had a student in
my team who had to provide some HTML information; I asked him to test
his data in two common browsers (back these days I think Netscape and
the MS IE), and (for obvious reasons), also with Lynx!

(Privately I had later written HTML/JS to create applications (with
dynamic content) since otherwise that would not have been possible;
I had no own server with some application servers available. But I
didn't use any frameworks or external libraries. Already bad enough.)

But even with Browsers and JS activated with my old Firefox I cannot
use or read many websites nowadays; because they demand newer browser
versions.

Janis

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

#11188 — Re: simplicity / complexity

>>>>> On 2025-08-27, Janis Papanagnou wrote:
>>>>> On 26.08.2025 20:42, Ivan Shmakov wrote:
>>>>> On 2025-08-19, Janis Papanagnou wrote:

 >>> Well, used software tools (and their updates) required me to at
 >>> least upgrade memory!  (That's actually one point that annoys me
 >>> in "modern" software development; rarely anyone seems to care
 >>> economizing resource requirements.)

 >> I doubt it's so much lack of care as it is simply being not a
 >> priority.

 > But those are depending each other.

	I guess I should've expressed myself better: engineering is
	all about trade-offs, and there're often other things to care
	about once the program runs "fast enough" on the hardware that
	the customers are /assumed/ to have.

	Not to mention that taking too long to 'polish' your product,
	you risk ending up lagging behind your competitors.

	I could only hope that environmental concerns will eventually
	make resource usage a more important issue for code writers.

 > And, to be yet more clear; I also think it's [widely] just ignorance!
 > (The mere existence of the article you quoted below is per se already a
 > strong sign for that.  But also other experiences, like talks with many
 > IT-folks of various age and background reinforced my opinion on that.)

	I suppose it might be the case of people involved with computers
	professionally not seeing much point in acquiring the skills that
	aren't in demand by employers.

 > (Privately I had later written HTML/JS to create applications (with
 > dynamic content) since otherwise that would not have been possible;
 > I had no own server with some application servers available.  But I
 > didn't use any frameworks or external libraries.  Already bad enough.)

	I can't say I'm a big fan of JS or ES, yet there're certainly
	languages I like even less.  FWIW, I prefer to stick to ES 5.1,
	http://262.ecma-international.org/5.1/ specifically, as then I
	can use http://duktape.org/ or http://mujs.com/ to test the
	bulk of my code, rather than running it in Chromium or Firefox.

	Like I've mentioned elsewhere, it's not the language, or even
	its use to create web applications, that irks me: it's that
	often enough when I want some data, what I get instead is some
	application that I /must/ use to access that same data - in a
	manner predefined by its developer (say, one record at a time),
	and not particularly conductive to the task /I/ have at hand.

	As to frameworks, my /impression/ is that it makes sense to
	familiarize oneself with them only when there're actually
	/lots/ of similar programming problems that need to be solved,
	particularly when writing code as part of a team.  As it never
	was the case for me personally, I've never seen much sense in
	investing effort into learning any framework, JS or otherwise.

 > But even with Browsers and JS activated with my old Firefox I cannot
 > use or read many websites nowadays; because they demand newer browser
 > versions.

	"Demand" how?

	Server-side code can of course make arbitrary decisions based
	on the User-Agent: string, but that's a poor practice in general,
	and typically such restrictions can be bypassed by reading the
	archived copy of the webpage from http://web.archive.org/ .

	Also works when it's not a browser but /TLS/ version issue.

	Alternatively, associated JS code can test browser's capabilities,
	but that can be circumvented by disabling JS altogether.

	Also to mention is that many websites these days rely on some
	sort of "DDoS protection service" external to them.  (I run my
	own servers, so I /do/ know some of the pain of mitigating heaps
	of junk requests originating from botnets - mainly compromised
	"wireless routers" I believe.)

	Such services employ captchas, and those in turn require JS,
	and might require recent browser versions as well.  If that's
	the case, http://web.archive.org/ might or might not help.

	Other than using Wayback Machine, I believe there's no easy
	solution to this problem: should the operator disable "protection
	service," they risk the site becoming bogged down by junk requests
	and no longer available to legitimate users.  Conversely, by
	employing such a service, they inconvenience their users, for
	even those who /do/ run modern browsers, will presumably have
	better things to do than solving captchas.

	So, personally, when encountering such behavior, I try Wayback
	Machine first.  If it doesn't get me a version of the webpage
	as recent as I need, I consider contacting the website operator
	so that they might check and possibly tweak their "protection"
	settings to allow archival.  If they can't, or won't, fix it,
	well, as mTCP HTTPSERV.EXE puts it, "countless more exist."

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

#11190 — Re: simplicity / complexity

On Sat, 30 Aug 2025 19:39:49 +0000, Ivan Shmakov wrote:

> Not to mention that taking too long to 'polish' your product, you
> risk ending up lagging behind your competitors.

I would say, the open-source world is a counterexample to this. Look at 
how long it took GNU and Linux to end up dominating the entire computing 
landscape -- it didn’t happen overnight.

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

#11199 — Re: simplicity / complexity

>>>>> On 2025-08-30, Lawrence D'Oliveiro wrote:
>>>>> On Sat, 30 Aug 2025 19:39:49 +0000, Ivan Shmakov wrote:

 >> Not to mention that taking too long to 'polish' your product, you
 >> risk ending up lagging behind your competitors.

 > I would say, the open-source world is a counterexample to this.
 > Look at how long it took GNU and Linux to end up dominating the
 > entire computing landscape -- it didn't happen overnight.

	Indeed, one good thing about free software is that when one
	company closes down, another can pick up and go on from there.
	Such as how Netscape is no more, yet the legacy of its Navigator
	still survives in Firefox.

	I'm not sure how much of a consolation it is to the people
	who owned the companies that failed, though.

	Also, what indication is there that GNU is 'dominating' the
	landscape?  Sure, Linux is everywhere (such as in now ubiquitous
	Android phones and TVs and whatnot), but I don't quite see GNU
	being adopted as widely.

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

#11200 — Re: simplicity / complexity

On Sun, 31 Aug 2025 13:35:51 +0000, Ivan Shmakov wrote:

> I'm not sure how much of a consolation it is to the people who owned
> the companies that failed, though.

Companies fail all the time, open source or no open source. When a
company that has developed a piece of proprietary software fails, then
the software dies with the company. With open source, the software
stands a chance of living on.

E.g. Loki was an early attempt at developing games on Linux. They
failed. But the SDL framework that they created for low-latency
multimedia graphics lives on.

> Also, what indication is there that GNU is 'dominating' the
> landscape?  Sure, Linux is everywhere (such as in now ubiquitous
> Android phones and TVs and whatnot), but I don't quite see GNU
> being adopted as widely.

Look at all the markets that Linux has taken away from Microsoft --
Windows Media Center, Windows Home Server -- all defunct. Windows
Server too is in slow decline. And now handheld gaming with the Steam
Deck. You will find GNU there.

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

#11219 — [OT] free software

>>>>> On 2025-08-31, Lawrence D'Oliveiro wrote:
>>>>> On Sun, 31 Aug 2025 13:35:51 +0000, Ivan Shmakov wrote:

 >> Indeed, one good thing about free software is that when one company
 >> closes down, another can pick up and go on from there.  Such as how
 >> Netscape is no more, yet the legacy of its Navigator still survives
 >> in Firefox.

 >> I'm not sure how much of a consolation it is to the people who owned
 >> the companies that failed, though.

 > Companies fail all the time, open source or no open source.  When
 > a company that has developed a piece of proprietary software fails,
 > then the software dies with the company.  With open source, the
 > software stands a chance of living on.

	It sounds like we're in agreement on this point, no?

	My other point, however, is this: when you do run a business,
	shouldn't you be more concerned that said /business/ succeeds,
	rather than the products it delivers, whatever they might be?

	And from where I stand, releasing software targetting tomorrow's
	computers is, as a rule, a better business practice - than
	targetting decade-old ones.

 > E.g. Loki was an early attempt at developing games on Linux.  They
 > failed.  But the SDL framework that they created for low-latency
 > multimedia graphics lives on.

	Yes, that too.  (Though I like my Firefox example better.)

 >> Also, what indication is there that GNU is 'dominating' the
 >> landscape?  Sure, Linux is everywhere (such as in now ubiquitous
 >> Android phones and TVs and whatnot), but I don't quite see GNU
 >> being adopted as widely.

 > Look at all the markets that Linux has taken away from Microsoft --
 > Windows Media Center, Windows Home Server -- all defunct.  Windows
 > Server too is in slow decline.

	I've had very little interest in Microsoft since the 1990s.
	About the only Microsoft-related news I've since paid attention
	to were that Microsoft contributed a fair chunk of code to Linux;
	that Microsoft acquired Github; and that Windows now has WSL.

	I have no idea what Windows Media Center is (or was), and what
	alternatives to it the GNU project, http://gnu.org/ , now offers.

	(I'd guess VLC and FFmpeg might be such alternatives, but last
	I've checked, they were not part of GNU.)

 > And now handheld gaming with the Steam Deck.  You will find GNU there.

	So I've read http://en.wikipedia.org/wiki/Steam_Deck and found
	out that the device runs SteamOS which, as of version 3.0, is
	based on Arch Linux, thus presumably retaining a fair chunk of
	GNU within.  (Bash, Coreutils, Libc, to guess a few packages.
	I doubt it includes GNU Emacs or GNU Chess, though.)

	That said, I'm not sure Steam Deck can /itself/ be said to
	dominate the market:

 w> Market research firm International Data Corporation estimated that
 w> between 3.7 and 4 million Steam Decks had been sold by the third
 w> anniversary of the device in February 2025.

	How big a market share of handheld gaming computers is 4e6?

	Also, I gather it's not a direct competitor to Android and
	Android-based mobile computers, right?

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

#11366 — Re: simplicity / complexity

Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 30 Aug 2025 19:39:49 +0000, Ivan Shmakov wrote:
> 
>> Not to mention that taking too long to 'polish' your product, you
>> risk ending up lagging behind your competitors.
> 
> I would say, the open-source world is a counterexample to this. Look at 
> how long it took GNU and Linux to end up dominating the entire computing 
> landscape -- it didn’t happen overnight.

Actually, open source nicely illustates this.  First advice to
open source projects is "release early, release often".  Projects
that delay release because they are "not ready" typically loose
and eventually die.

Open source projects typically want to offer high quality.  But
they have to limit their efforts to meet realease schedules.
There are compromises which know bugs get fixed: some are deemed
serious enough to block new release, but a lot get shipped.
There is internal testing, but significant part of problems
get discovered only after release.

One can significantly increase quality by limiting addition of
new featurs.  But open source projects that try to do this
typically loose.

-- 
                              Waldek Hebisch

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

#11367 — Re: simplicity / complexity

On 08.10.2025 16:03, Waldek Hebisch wrote:
> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 30 Aug 2025 19:39:49 +0000, Ivan Shmakov wrote:
>>
>>> Not to mention that taking too long to 'polish' your product, you
>>> risk ending up lagging behind your competitors.
>>
>> I would say, the open-source world is a counterexample to this. Look at 
>> how long it took GNU and Linux to end up dominating the entire computing 
>> landscape -- it didn’t happen overnight.
> 
> Actually, open source nicely illustates this.  First advice to
> open source projects is "release early, release often".  Projects
> that delay release because they are "not ready" typically loose
> and eventually die.
> 
> Open source projects typically want to offer high quality.  But
> they have to limit their efforts to meet realease schedules.
> There are compromises which know bugs get fixed: some are deemed
> serious enough to block new release, but a lot get shipped.
> There is internal testing, but significant part of problems
> get discovered only after release.
> 
> One can significantly increase quality by limiting addition of
> new featurs.  But open source projects that try to do this
> typically loose.

We can observe that software grows, and grows rank. My experience
is that it makes sense to plan and occasionally add refactoring
cycles in these cases. (There's also software planned accurately
from the beginning, software that changes less, and is only used
for its fixed designed purpose. But we're not speaking about that
here.) A principal advantage of the "open-source world" (or rather
the non-commercial world) is that there's neither competition nor
need to quickly throw things into the market. So this area has at
least the chance to adapt plans and contents without time pressure.
Whether it's done is another question (and project specific). It
should also be mentioned that some projects have e.g. security or
quality requirements that gets tested and measured and require some
adaptive process to increase these factors (without adding anything
new).

Janis

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

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

Back to top | Article view | comp.lang.misc

csiph-web