Groups | Search | Server Info | Login | Register

Groups > comp.lang.misc > #11220

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

Show all headers | View raw

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

Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

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