[TUHS] Macs and future unix derivatives

[TUHS] Macs and future unix derivatives

[Will Senn]

[-- Attachment #1: Type: text/plain, Size: 3273 bytes --]

All,

I was introduced to Unix in the mid 1990's through my wife's VMS account 
at UT Arlington, where they had a portal to the WWW. I was able to 
download Slackware with the 0.9 kernel on 11 floppies including X11. I 
installed this on my system at the time - either a DEC Rainbow 100B? or 
a handme down generic PC. A few years later at Western Illinois 
University - they had some Sun Workstations there and I loved working 
with them. It would be several years later, though, that I would 
actually use unix in a work setting - 1998. I don't even remember what 
brand of unix, but I think it was again, sun, though no gui, so not as 
much love. Still, I was able to use rcs and and when my Windows bound 
buddies lost a week's work because of some snafu with their backups, I 
didn't lose anything - jackflash was the name of the server - good 
memories :). However, after this it was all DOS and Windows until, 2005.

I'd been eyeing Macs for some time. I like the visual aesthetics and 
obvious design considerations. But, in 2005, I finally had a bonus big 
enough to actually buy one. I bought a G5 24" iMac and fell in love with 
Mac. Next, it was a 15" G4 Powerbook. I loved those Macs until Intel 
came around and then it was game over, no more PC's in my life (not 
really, but emotionally, this was how I felt). With Mac going intel, I 
could dual boot into Windows, Triple boot into Linux, and Quadruple boot 
into FreeBSD, and I could ditch Fink and finally manage my unix tools 
properly (arguable, I know) with Homebrew or MacPorts (lately, I've gone 
back to MacPorts due to Homebrew's lack of support for older OS 
versions, and for MacPorts seeming rationality).

Anyhow, I have thoroughly enjoyed the Mac ride, but with Catalina, the 
ride got really bumpy (too much phone home, no more 32 bit programs and 
since Adobe Acrobat X, which I own, outright, isn't 64 bit, among other 
apps, this just in not an option for me), and with Big Sur, it's gotten 
worse, potholes, sinkholes, and suchlike, and the interface is downright 
patronizing (remember Microsoft Bob?). So, here I am, Mr. 
Run-Any-Cutting-Edge-OS anytime guy, hanging on tooth and nail to Mac OS 
Mojave where I still have a modicum of control over my environment.

My thought for the day and question for the group is... It seems that 
the options for a free operating system (free as in freedom) are 
becoming ever more limited - Microsoft, this week, announced that their 
Edge update will remove Edge Legacy and IE while doing the update - 
nuts; Mac's desktop is turning into IOS - ew, ick; and Linux is wild 
west meets dictatorship and major corporations are moving in to set 
their direction (Microsoft, Oracle, IBM, etc.). FreeBSD we've beat to 
death over the last couple of weeks, so I'll leave it out of the mix for 
now. What in our unix past speaks to the current circumstance and what 
do those of you who lived those events see as possibilities for the next 
revolution - and, will unix be part of it?

And a bonus question, why, oh why, can't we have a contained kernel that 
provides minimal functionality (dare I say microkernel), that is 
securable, and layers above it that other stuff (everything else) can 
run on with auditing and suchlike for traceability?






[-- Attachment #2: Type: text/html, Size: 3855 bytes --]

Re: [TUHS] Macs and future unix derivatives

[Larry McVoy]

On Mon, Feb 08, 2021 at 12:11:08PM -0600, Will Senn wrote:
> And a bonus question, why, oh why, can't we have a contained kernel that
> provides minimal functionality (dare I say microkernel), that is securable,
> and layers above it that other stuff (everything else) can run on with
> auditing and suchlike for traceability?

I can answer the microkernel question I think.  It's discipline.
The only microkernel I ever liked was QNX and I liked it because it was
a MICROkernel.  The entire kernel easily fit in a 4K instruction cache.

The only way that worked was discipline.  There were 3 guys who could
touch the kernel, one of them, Dan Hildebrandt, was sort of a friend
of mine, we could, and did, have conversations about the benefits of a
monokernel vs a microkernel.  He agreed with me that QNX only worked
because those 3 guys were really careful about what went into the
kernel.  There was none of this "Oh, I measured performance and it is
only 1.5% slower now" nonsense, that's death by a hundred paper cuts.
Instead, every change came with before and after cache miss counts
under a benchmark.  Stuff that increased the cache misses was heavily
frowned upon.

Most teams don't have that sort of discipline.  They say they do,
they think they do, but when marketing says we have to do $WHATEVER,
it goes in.

Re: [TUHS] Macs and future unix derivatives

[Justin Coffey]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

On Mon, Feb 8, 2021 at 10:22 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Mon, Feb 08, 2021 at 12:11:08PM -0600, Will Senn wrote:
> > And a bonus question, why, oh why, can't we have a contained kernel that
> > provides minimal functionality (dare I say microkernel), that is
> securable,
> > and layers above it that other stuff (everything else) can run on with
> > auditing and suchlike for traceability?
>
> I can answer the microkernel question I think.  It's discipline.
> The only microkernel I ever liked was QNX and I liked it because it was
> a MICROkernel.  The entire kernel easily fit in a 4K instruction cache.
>
> The only way that worked was discipline.  There were 3 guys who could
> touch the kernel, one of them, Dan Hildebrandt, was sort of a friend
> of mine, we could, and did, have conversations about the benefits of a
> monokernel vs a microkernel.  He agreed with me that QNX only worked
> because those 3 guys were really careful about what went into the
> kernel.  There was none of this "Oh, I measured performance and it is
> only 1.5% slower now" nonsense, that's death by a hundred paper cuts.
> Instead, every change came with before and after cache miss counts
> under a benchmark.  Stuff that increased the cache misses was heavily
> frowned upon.
>
> Most teams don't have that sort of discipline.  They say they do,
> they think they do, but when marketing says we have to do $WHATEVER,
> it goes in.
>

This describes pretty much every project I've ever worked on.  It starts
small, with a manageable feature set and a clean and performant codebase
and then succumbs to external pressure for features and slowly bloats.  If
the features prove useful then the project will live on of course (and
those features may well be the reason the project lives on), but at some
point the bloat and techdebt become the dominant development story.

My question then is, are there any examples of projects that maintained
discipline, focus and relevance over years/decades that serve as counter
examples to the above statement(s)?  OpenBSD?  Go?  Is there anything to
learn here?

-Justin
-- 
+1 (858) 230-1436
jqcoffey@gmail.com
-----

[-- Attachment #2: Type: text/html, Size: 2813 bytes --]

Re: [TUHS] Macs and future unix derivatives

[Larry McVoy]

On Mon, Feb 08, 2021 at 10:32:03AM -0800, Justin Coffey wrote:
> My question then is, are there any examples of projects that maintained
> discipline, focus and relevance over years/decades that serve as counter
> examples to the above statement(s)?  OpenBSD?  Go?  Is there anything to
> learn here?

I also think it is team size.  We never had more than 8 engineers on
BitKeeper, and the core was really 4, and we kept adding features and the
main code topped out at 128K lines.  It got to 120K or so pretty quickly
and then we just kept pushing for changesets that removed as much code
as they added, bonus points for when they removed more than they added.

I think if we had more people it would have been harder to keep things
small and clean.

Re: [TUHS] Macs and future unix derivatives

[Theodore Ts'o]

On Mon, Feb 08, 2021 at 10:32:03AM -0800, Justin Coffey wrote:
> This describes pretty much every project I've ever worked on.  It starts
> small, with a manageable feature set and a clean and performant codebase
> and then succumbs to external pressure for features and slowly bloats.  If
> the features prove useful then the project will live on of course (and
> those features may well be the reason the project lives on), but at some
> point the bloat and techdebt become the dominant development story.

The problem is users all want a different set of features.  One
person's "small and clean" is another person's "missing critical
feature".

This is one of the problems which the Linux enterprise distro's see.
Everyone wants everything to stay the same --- except for their own
pet feature.  Or because they want their new hardware (say, NVMe,
which wasn't present in the version of the Linux kernel that was
frozen for the enterprise distro three years ago).

Ultimately, the reason why you can't have what you want boils down to
sheer economics.  If you want to pay a small team to give you exactly
what you want, but nothing else, then sure, you can have what you
want.  If you and two dozen want _exactly_ the same thing, then it
will be a lot cheaper.  But if you want something which is free as in
beer, or even the cost of iOS, then it needs to have all of the
features and hardware support for a much larger set of customers.

It's interesting that some folks are complaining about "elistism"; but
they don't seem to recognize that asking for something super small and
clean, that is inherently elitist.  I also suspect they don't
*actually* want something _that_ small, in terms of feature set.  Do
they *really* want something which is just V7 Unix, with nothing else?
No TCP/IP, no hot-plug USB support?  No web browsing?

If so, it shouldn't be that hard to squeeze a PDP-11 into a laptop
form factor, and they can just run V7 Unix.  Easy-peasy!

Oh, you wanted more than that?  Feature bloat!  Feature bloat!
Feature bloat!   Shame!  Shame!   Shame!

						- Ted

Re: [TUHS] Macs and future unix derivatives

[Angel M Alganza]

On Mon, Feb 08, 2021 at 10:32:03AM -0800, Justin Coffey wrote:

> My question then is, are there any examples of projects that maintained
> discipline, focus and relevance over years/decades that serve as counter
> examples to the above statement(s)?  OpenBSD?  Go?  Is there anything to
> learn here?

I think OpenBSD, yes, and also Haiku.  Every so often somebody argues
that they need to do this or that, and release an stable (not beta)
version, if they want to compete with orher OS.  Their answer is always
that they will release it when it's ready and that they aren't try to
compete for a "market" share or anything, but ship a good product when
it's right.  I don't know if that will remain true after they ship R1
(binary compatible with BeOS R5), or if they will feel free to start
adding things in for other reasons than making the best OS they can, and
frack it up.  I hope not!

Regards.
Ángel

Re: [TUHS] Macs and future unix derivatives

[Henry Bent]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

On Mon, 8 Feb 2021 at 13:12, Will Senn <will.senn@gmail.com> wrote:

>
> Anyhow, I have thoroughly enjoyed the Mac ride, but with Catalina, the
> ride got really bumpy (too much phone home, no more 32 bit programs and
> since Adobe Acrobat X, which I own, outright, isn't 64 bit, among other
> apps, this just in not an option for me), and with Big Sur, it's gotten
> worse, potholes, sinkholes, and suchlike, and the interface is downright
> patronizing (remember Microsoft Bob?). So, here I am, Mr.
> Run-Any-Cutting-Edge-OS anytime guy, hanging on tooth and nail to Mac OS
> Mojave where I still have a modicum of control over my environment.
>

I hear you on this one.  I'm sticking with Mojave as well on my Mac laptop,
but part of that is also because I refuse to give up on what is now an
almost eight year old machine that has no real problems and has all of the
hardware and ports I want.  Apple loves to move quickly and abandon
compatibility, and in that respect it's an interesting counterpoint to
Linux or a *BSD where you can have decades old binaries that still run.


>
> And a bonus question, why, oh why, can't we have a contained kernel that
> provides minimal functionality (dare I say microkernel), that is securable,
> and layers above it that other stuff (everything else) can run on with
> auditing and suchlike for traceability?
>

Oh no, not this can of worms... I bet Clem has quite a bit to say about
this, but I'll boil it down to this: Mach bombed spectacularly (check out
the Wikipedia article, it's pretty decent) and set the idea in people's
heads that microkernels were not the way to go.  If you wanted to write a
microkernel OS today IMHO you'd need to be fully UNIX compatible, and you'd
need to natively write EVERY syscall so that performance isn't horrible.
This has turned out to be much harder than one might think at first
glance.  Just ask the GNU Hurd folks...  All said, this is probably a space
where the time and effort required to squeeze the last 10%, or 5%, or 1% of
performance out of the hardware just isn't worth the time investment.

-Henry

[-- Attachment #2: Type: text/html, Size: 2874 bytes --]

Re: [TUHS] Macs and future unix derivatives

[John Gilmore]

Henry Bent <henry.r.bent@gmail.com> wrote:
>     	   			    Apple loves to move quickly and abandon
> compatibility, and in that respect it's an interesting counterpoint to
> Linux or a *BSD where you can have decades old binaries that still run.

That was true decades ago, but no longer.  In the intervening time, all
the major Linux distributions have stopped releasing OS's that support
32-bit machines.  Even those that support 32-bit CPUs have often
desupported the earlier CPUs (like, what was wrong with the 80386?).
Essentially NO applications require 64-bit address spaces, so arguably
if they wanted to lessen their workload, they should have desupported
the 64-bit architectures (or made kernels and OS's that would run on
both from a single release).  But that wouldn't give them the
gee-whiz-look-at-all-the-new-features feeling.

I ran 32-bit OS releases on all my 64-bit x86 hardware for years.  They
ran faster and smaller than the amd64 versions, and also ran old
binaries for more than a decade.  But their vendors and support teams
decided that doing the release-engineering to keep them running was more
work than pulling the plug.

Even Fedora has desupported the One Laptop Per Child hardware now -- no
new releases for millions of kids!  And desupported all the other cheap
Intel mobile CPUs, let alone your typical desktop 80386, 80486, or
Pentium.  Have you tried running Linux on a machine without a GPU
these days?  It's truly sad that to gain stupid animated window tricks,
they broke compatability with millions of existing systems.

Here's one overview of the niche distros that still have x86 support:

  https://fossbytes.com/best-lightweight-linux-distros/

Even those are dropping like flies, e.g. Ubuntu MATE now says "For older
hardware based on i386. Supported until April 2021", i.e. only til next
month!  The PuppyLinux.com web site is now a 404.  Etc.

(I'm not up on what the BSD releases are doing.)

	John
	

Re: [TUHS] Macs and future unix derivatives

[Michael Huff]

On 2/8/2021 9:55 PM, John Gilmore wrote:
> Henry Bent <henry.r.bent@gmail.com> wrote:
>>      	   			    Apple loves to move quickly and abandon
>> compatibility, and in that respect it's an interesting counterpoint to
>> Linux or a *BSD where you can have decades old binaries that still run.
> That was true decades ago, but no longer.  In the intervening time, all
> the major Linux distributions have stopped releasing OS's that support
> 32-bit machines.  Even those that support 32-bit CPUs have often
> desupported the earlier CPUs (like, what was wrong with the 80386?).
> Essentially NO applications require 64-bit address spaces, so arguably
> if they wanted to lessen their workload, they should have desupported
> the 64-bit architectures (or made kernels and OS's that would run on
> both from a single release).  But that wouldn't give them the
> gee-whiz-look-at-all-the-new-features feeling.
>
> I ran 32-bit OS releases on all my 64-bit x86 hardware for years.  They
> ran faster and smaller than the amd64 versions, and also ran old
> binaries for more than a decade.  But their vendors and support teams
> decided that doing the release-engineering to keep them running was more
> work than pulling the plug.
>
> Even Fedora has desupported the One Laptop Per Child hardware now -- no
> new releases for millions of kids!  And desupported all the other cheap
> Intel mobile CPUs, let alone your typical desktop 80386, 80486, or
> Pentium.  Have you tried running Linux on a machine without a GPU
> these days?  It's truly sad that to gain stupid animated window tricks,
> they broke compatability with millions of existing systems.
>
> Here's one overview of the niche distros that still have x86 support:
>
>    https://fossbytes.com/best-lightweight-linux-distros/
>
> Even those are dropping like flies, e.g. Ubuntu MATE now says "For older
> hardware based on i386. Supported until April 2021", i.e. only til next
> month!  The PuppyLinux.com web site is now a 404.  Etc.
>
> (I'm not up on what the BSD releases are doing.)
>
> 	John

i386 has been demoted on FreeBSD: 
https://lists.freebsd.org/pipermail/freebsd-announce/2021-January/002006.html

I don't think there's any change on NetBSD, no idea about OpenBSD but I 
assume they're the same.

In all honest, I don't think that backwards compatibility has ever been 
that great on Linux -at least not for the last twenty or so years, in my 
(limited) experience. It's not like Solaris where you could build on 2.4 
and there's a good chance it will run on 11 or at least 10.

Re: [TUHS] Macs and future unix derivatives

[Greg A. Woods]

[-- Attachment #1: Type: text/plain, Size: 3235 bytes --]

Henry Bent <henry.r.bent@gmail.com> wrote:
>      	   			    Apple loves to move quickly and
> abandon compatibility, and in that respect it's an interesting
> counterpoint to Linux or a *BSD where you can have decades old
> binaries that still run.

Nothing in the open-source (OS) world churns and moves around and grows
and wiggles as much as Linux.  The rate of change of the kernel is
simply incomprehensibly staggering.  Linux userland isn't much better
off.

In the commercial (OS) world Microsoft might be churning at a similar
rate.  Apple on the other hand is relatively stable by comparison -- too
stable at times and not always regularly picking up fixes from
third-party projects they make use of.  Apple is guilty of extreme churn
in their GUI though -- at least from a user's perspective (perhaps their
APIs are a bit more stable, but somehow from observing them from afar I
highly doubt it).  Apple's ABIs seem relatively stable -- I still run a
few binary apps (albeit quite simple ones) I installed over a decade ago
and haven't updated since.


At Mon, 8 Feb 2021 22:05:57 -0900, Michael Huff <mphuff@gmail.com> wrote:
Subject: Re: [TUHS] Macs and future unix derivatives
>
> I don't think there's any change on NetBSD, no idea about OpenBSD but
> I assume they're the same.


Indeed, NetBSD/i386 is still a "tier 1" port as of the 9.1 release last
fall:

	http://wiki.NetBSD.org/ports/

Note there is a caveat with regard to true 80386:  "Any i486 or better
CPU should work - genuine Intel or a compatible such as Cyrix, AMD, or
NexGen."

Also NetBSD comes with a good group of compatability and emulation
modules for its kernel ABI, including support for both all of its own
older releases, as well as for port-specific third-party ABI emulations,
such as Linux and SCO Unix.

See for example:  https://wiki.NetBSD.org/guide/linux/

I've only once ever needed to run a Linux binary, and quite a long time
ago, so I'm not so up to date on these things, but it may well be that
NetBSD/i386 can run old 32-bit Linux i386 binaries better than any
current release of Linux.

Personally I work in a world where there's source code for every
application I use, which means I generally only need backward
compatability for the earliest release I might be running at any given
time -- I.e. just enough to keep things running after an upgrade while I
get it all re-compiled and tested.

> In all honest, I don't think that backwards compatibility has ever
> been that great on Linux -at least not for the last twenty or so
> years, in my (limited) experience.

Really good backward compatability for older kernel and library ABIs is
a cornerstone of NetBSD release engineering.  It is very well designed
and implemented and it is pretty much guaranteed to work or get fixed.
Unlike Linux it doesn't rely on shared libraries to work, and also the
system shared libraries have very good backward compatability support as
well.  I.e. NetBSD backward compatability is far more complete and
reliable at all levels (including ABIs and their APIs)

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [TUHS] Macs and future unix derivatives

[Will Senn]

On 2/9/21 12:55 AM, John Gilmore wrote:
> Henry Bent <henry.r.bent@gmail.com> wrote:
>>      	   			    Apple loves to move quickly and abandon
>> compatibility, and in that respect it's an interesting counterpoint to
>> Linux or a *BSD where you can have decades old binaries that still run.
> That was true decades ago, but no longer.  In the intervening time, all
> the major Linux distributions have stopped releasing OS's that support
> 32-bit machines.  Even those that support 32-bit CPUs have often
> desupported the earlier CPUs (like, what was wrong with the 80386?).
> Essentially NO applications require 64-bit address spaces, so arguably
> if they wanted to lessen their workload, they should have desupported
> the 64-bit architectures (or made kernels and OS's that would run on
> both from a single release).  But that wouldn't give them the
> gee-whiz-look-at-all-the-new-features feeling.
>
> I ran 32-bit OS releases on all my 64-bit x86 hardware for years.  They
> ran faster and smaller than the amd64 versions, and also ran old
> binaries for more than a decade.  But their vendors and support teams
> decided that doing the release-engineering to keep them running was more
> work than pulling the plug.
>
> Even Fedora has desupported the One Laptop Per Child hardware now -- no
> new releases for millions of kids!  And desupported all the other cheap
> Intel mobile CPUs, let alone your typical desktop 80386, 80486, or
> Pentium.  Have you tried running Linux on a machine without a GPU
> these days?  It's truly sad that to gain stupid animated window tricks,
> they broke compatability with millions of existing systems.
>
> Here's one overview of the niche distros that still have x86 support:
>
>    https://fossbytes.com/best-lightweight-linux-distros/
>
> Even those are dropping like flies, e.g. Ubuntu MATE now says "For older
> hardware based on i386. Supported until April 2021", i.e. only til next
> month!  The PuppyLinux.com web site is now a 404.  Etc.
>
> (I'm not up on what the BSD releases are doing.)
>
> 	John
> 	
Sigh... 32bit will be 2nd tier in FreeBSD 13 :)

Re: [TUHS] Macs and future unix derivatives

[Theodore Ts'o]

On Mon, Feb 08, 2021 at 10:55:50PM -0800, John Gilmore wrote:
> 
> That was true decades ago, but no longer.  In the intervening time, all
> the major Linux distributions have stopped releasing OS's that support
> 32-bit machines.  Even those that support 32-bit CPUs have often
> desupported the earlier CPUs (like, what was wrong with the 80386?).
> Essentially NO applications require 64-bit address spaces, so arguably
> if they wanted to lessen their workload, they should have desupported
> the 64-bit architectures (or made kernels and OS's that would run on
> both from a single release).  But that wouldn't give them the
> gee-whiz-look-at-all-the-new-features feeling.

So there is currently a *single* volunteer supporting the 32-bit i386
platform for Debian, and in December 2020 there was an e-mail thread
asking whether there were volunteer resources to be able to provide
the necessary support (testing installers, building and testing
packages for security updates, etc.) for the 3.5 years of stable
support.  I don't believe the final decision has been made, but if
more people were willing to volunteer to make it happen, or to pay $$$
to provide that support, I'm sure Debian would be very happy to keep
i386 on life support for the next stable release.

Ultimately, it's all about what people are willing to support by
providing direct volunteer support, or by putting the money where
their mouth is.  "We have met the enemy, and he is us."

					- Ted

Re: [TUHS] Macs and future unix derivatives

[Larry McVoy]

On Tue, Feb 09, 2021 at 02:02:34PM -0500, Theodore Ts'o wrote:
> On Mon, Feb 08, 2021 at 10:55:50PM -0800, John Gilmore wrote:
> > That was true decades ago, but no longer.  In the intervening time, all
> > the major Linux distributions have stopped releasing OS's that support
> > 32-bit machines.  Even those that support 32-bit CPUs have often
> > desupported the earlier CPUs (like, what was wrong with the 80386?).

Um, John, it's 33mhz part.  Who wants that?

> So there is currently a *single* volunteer supporting the 32-bit i386
> platform for Debian, and in December 2020 there was an e-mail thread
> asking whether there were volunteer resources to be able to provide
> the necessary support (testing installers, building and testing
> packages for security updates, etc.) for the 3.5 years of stable
> support.  

John is one damn good programmer, maybe he'll offer.

--lm

Re: [TUHS] Macs and future unix derivatives

[Wesley Parish]

Many of those mentioned in the fossbytes article have become 64-bit
only. But I can recommend Anti-X (pronounced Antics) as a suitable OS
for an old-but-good i386 box or laptop.

Wesley Parish

On 2/9/21, John Gilmore <gnu@toad.com> wrote:
> Henry Bent <henry.r.bent@gmail.com> wrote:
>>     	   			    Apple loves to move quickly and abandon
>> compatibility, and in that respect it's an interesting counterpoint to
>> Linux or a *BSD where you can have decades old binaries that still run.
>
> That was true decades ago, but no longer.  In the intervening time, all
> the major Linux distributions have stopped releasing OS's that support
> 32-bit machines.  Even those that support 32-bit CPUs have often
> desupported the earlier CPUs (like, what was wrong with the 80386?).
> Essentially NO applications require 64-bit address spaces, so arguably
> if they wanted to lessen their workload, they should have desupported
> the 64-bit architectures (or made kernels and OS's that would run on
> both from a single release).  But that wouldn't give them the
> gee-whiz-look-at-all-the-new-features feeling.
>
> I ran 32-bit OS releases on all my 64-bit x86 hardware for years.  They
> ran faster and smaller than the amd64 versions, and also ran old
> binaries for more than a decade.  But their vendors and support teams
> decided that doing the release-engineering to keep them running was more
> work than pulling the plug.
>
> Even Fedora has desupported the One Laptop Per Child hardware now -- no
> new releases for millions of kids!  And desupported all the other cheap
> Intel mobile CPUs, let alone your typical desktop 80386, 80486, or
> Pentium.  Have you tried running Linux on a machine without a GPU
> these days?  It's truly sad that to gain stupid animated window tricks,
> they broke compatability with millions of existing systems.
>
> Here's one overview of the niche distros that still have x86 support:
>
>   https://fossbytes.com/best-lightweight-linux-distros/
>
> Even those are dropping like flies, e.g. Ubuntu MATE now says "For older
> hardware based on i386. Supported until April 2021", i.e. only til next
> month!  The PuppyLinux.com web site is now a 404.  Etc.
>
> (I'm not up on what the BSD releases are doing.)
>
> 	John
> 	
>

Re: [TUHS] Macs and future unix derivatives

[Dan Stromberg]

[-- Attachment #1: Type: text/plain, Size: 1364 bytes --]

On Mon, Feb 8, 2021 at 10:12 AM Will Senn <will.senn@gmail.com> wrote:

> All,
>


> My thought for the day and question for the group is... It seems that the
> options for a free operating system (free as in freedom) are becoming ever
> more limited - Microsoft, this week, announced that their Edge update will
> remove Edge Legacy and IE while doing the update - nuts; Mac's desktop is
> turning into IOS - ew, ick; and Linux is wild west meets dictatorship and
> major corporations are moving in to set their direction (Microsoft, Oracle,
> IBM, etc.). FreeBSD we've beat to death over the last couple of weeks, so
> I'll leave it out of the mix for now. What in our unix past speaks to the
> current circumstance and what do those of you who lived those events see as
> possibilities for the next revolution - and, will unix be part of it?
>
> And a bonus question, why, oh why, can't we have a contained kernel that
> provides minimal functionality (dare I say microkernel), that is securable,
> and layers above it that other stuff (everything else) can run on with
> auditing and suchlike for traceability?
>

I love Linux, especially Debian lately.

But I also have high hopes for Redox OS, and may switch someday:
https://en.wikipedia.org/wiki/Redox_(operating_system)
https://www.theregister.com/2019/11/29/after_four_years_rusty_os_nearly_selfhosting/

[-- Attachment #2: Type: text/html, Size: 2335 bytes --]

Re: [TUHS] Macs and future unix derivatives

[Angel M Alganza]

On Mon, Feb 08, 2021 at 10:43:54AM -0800, Dan Stromberg wrote:

> I love Linux, especially Debian lately.

I used Debian everywhere (desktops, laptops, servers) both at work and
at home.  Until they decided to ship it with SystemD and don't give an
alternative.  I then switched to Devuan, and I can't be happier.  It's
the exact wonderful Debian experience, with the freedom of choice that
Debian always gave me until it didn't anymore.   I used to say I would
go back in a heart beat if it gave an init alternative to SystemD, but
I don't think I would anymore.

> But I also have high hopes for Redox OS, and may switch someday:
> https://en.wikipedia.org/wiki/Redox_(operating_system)
> https://www.theregister.com/2019/11/29/after_four_years_rusty_os_nearly_selfhosting/

Me too, as well as for Haiku OS, even though it's not a UN!X derivative,
it's POSIX compliant (or so they claim), and it works very nicely as a
desktop OS.

Cheers,
Ángel

Re: [TUHS] Macs and future unix derivatives

[Thomas Paulsen]

[-- Attachment #1: Type: text/html, Size: 4213 bytes --]

Re: [TUHS] Macs and future unix derivatives

[Dave Horsfall]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Mon, 8 Feb 2021, Thomas Paulsen wrote:

> I'm a UNIX man since the days of Sys4R4. Since then I run Linux and 
> nothing else than Linux, no dual, triple, quadruple boot into anything 
> else. To be honest I don't like Apple because it's an elitist system: 
> People pay at least one thousand bucks just for the feel like being part 
> of a superior elite. Under Sys4R4 me and 50 others shared one big 
> resource: no place for any elitist movement.

I've been a Unix bod since Edition 5, and I run a few systems (Mac, 
FreeBSD, Penguin); I don't consider myself to be an elitist (unless you 
consider "Anything But Windoze" to be elitist).

I also paid only about $300 for my 2nd-hand MacBook Pro, and it works
fine.

-- Dave

Re: [TUHS] Macs and future unix derivatives

[Al Kossow]

On 2/8/21 10:11 AM, Will Senn wrote:

> Anyhow, I have thoroughly enjoyed the Mac ride, but with Catalina, the ride got really bumpy 

The problem now is they have broken enough of the APIs that developers aren't willing to support old
useful releases. Even MAME has recently been forced to abandon support for perfectly functioning machines before
10.15 and I have no desire to purchase any Apple product capable of running that release.

Re: [TUHS] Macs and future unix derivatives

[Andrew Warkentin]

On 2/8/21, Will Senn <will.senn@gmail.com> wrote:
>
> My thought for the day and question for the group is... It seems that
> the options for a free operating system (free as in freedom) are
> becoming ever more limited - Microsoft, this week, announced that their
> Edge update will remove Edge Legacy and IE while doing the update -
> nuts; Mac's desktop is turning into IOS - ew, ick; and Linux is wild
> west meets dictatorship and major corporations are moving in to set
> their direction (Microsoft, Oracle, IBM, etc.). FreeBSD we've beat to
> death over the last couple of weeks, so I'll leave it out of the mix for
> now. What in our unix past speaks to the current circumstance and what
> do those of you who lived those events see as possibilities for the next
> revolution - and, will unix be part of it?
>

Yes, those are almost exactly my thoughts on the current state of
OSes. I'm hoping that I can change it by writing my own OS
<https://gitlab.com/uxrt/>, because I don't see anyone else making
anything that I consider to be a particularly good effort to solve
those issues. However, it's still anyone's guess as to whether I will
succeed. I'm trying to give it every chance of success that I can
though by using existing code wherever possible and focusing on
compatibility with Linux (or at least I will be once I get to that
point).

BTW, I welcome any contributions to UX/RT. I currently am still only
working on the allocation subsystem (it's a bit trickier under seL4
than it would be on bare metal due to having to manage capabilities as
well as memory), but I think I am pretty close to being able to move
on.

>
> And a bonus question, why, oh why, can't we have a contained kernel that
> provides minimal functionality (dare I say microkernel), that is
> securable, and layers above it that other stuff (everything else) can
> run on with auditing and suchlike for traceability?
>

A lot of people still seem to believe that microkernels are inherently
slow, even though fast microkernels (specifically QNX) predate the
slow ones by several years. Also, it seems as if much of the academic
microkernel community thinks that there's a need to abandon Unix-like
architecture entirely and relegate Unix programs to some kind of
"penalty box" compatibility layer, but I don't see any reason why that
is the case. Certainly there are a lot of old Unix features that could
be either reimplemented in terms of something more modern or just
dropped entirely where doing so wouldn't break compatibility, but I
still think it's possible to write a modern microkernel-native
Unix-like OS that does most of what the various proposed or existing
incompatible OSes do.

>
> I can answer the microkernel question I think.  It's discipline.
> The only microkernel I ever liked was QNX and I liked it because it was
> a MICROkernel.  The entire kernel easily fit in a 4K instruction cache.
>
> The only way that worked was discipline.  There were 3 guys who could
> touch the kernel, one of them, Dan Hildebrandt, was sort of a friend
> of mine, we could, and did, have conversations about the benefits of a
> monokernel vs a microkernel.  He agreed with me that QNX only worked
> because those 3 guys were really careful about what went into the
> kernel.  There was none of this "Oh, I measured performance and it is
> only 1.5% slower now" nonsense, that's death by a hundred paper cuts.
> Instead, every change came with before and after cache miss counts
> under a benchmark.  Stuff that increased the cache misses was heavily
> frowned upon.
>
> Most teams don't have that sort of discipline.  They say they do,
> they think they do, but when marketing says we have to do $WHATEVER,
> it goes in.
>

I still don't get why QNX hasn't had more influence on anything else
even though it's been fairly successful commercially. If i am
successful, UX/RT will only be the second usable non-QNX OS with
significant QNX influence that I am aware of (after VSTa; there have
been a couple other attempts at free QNX-like systems that I am aware
of but they haven't really produced anything that could be considered
complete).

seL4 is fairly similar to QNX's kernel both in terms of architecture
and design philosophy. That's why I'm using it in UX/RT. I may end up
having to fork it at some point, but I am still going to keep to a
strict policy of not adding something to the kernel unless there is no
other way to reasonably implement it. For the sake of extensibility
and security I'm also going to have a strict policy against adding
non-file-based primitives of any kind, which is something that QNX
hasn't done (no other OS has AFAICT, not even Plan 9, since it has
anonymous memory, whereas UX/RT will use memory-mapped files in a
tmpfs instead).

On 2/8/21, Dan Stromberg <drsalists@gmail.com> wrote:
>
> But I also have high hopes for Redox OS, and may switch someday:
> https://en.wikipedia.org/wiki/Redox_(operating_system)
> https://www.theregister.com/2019/11/29/after_four_years_rusty_os_nearly_selfhosting/
>

The biggest problem I see with Redox is that they insist on writing
everything from scratch, whereas with UX/RT I am going to use existing
code wherever it is reasonable (this includes using the LKL project to
get access to basically the full range of Linux device drivers,
filesystems, and network protocols). Also, their VFS architecture is a
bit questionable IMO. Otherwise I might have been inclined to just
contribute to Redox (UX/RT will use quite a bit of Rust, but it won't
try to be a "Rust OS" like Redox is). I may end up incorporating more
code from Redox though (I'm already going to use their heap allocator
but will enhance it with dynamic resizing of the heap).

In addition they claim it to be a microkernel when it is actually a
Plan 9-style hybrid, since the kernel includes a bunch of Unix system
calls as primitives, disqualifying it from being a microkernel. This
is unlike QNX where the process server that implements the core of the
Unix API is built into the kernel but accessed entirely through IPC
and not through its own system calls (the UX/RT process server will be
similar in scope to that of QNX and will similarly lack any kind of
multi-personality infrastructure and be built alongside the kernel,
but will be a separate binary).

Re: [TUHS] QNX

[John Gilmore]

Andrew Warkentin <andreww591@gmail.com> wrote:
> A lot of people still seem to believe that microkernels are inherently
> slow, even though fast microkernels (specifically QNX) predate the
> slow ones by several years.

Wait, are we talking about the same operating system called QNX?

We had a customer at Cygnus in the 1990s (perhaps QNX itself) who wanted
us to port the GNU compilers to it.  It was the slowest, buggiest system
we ever tried to run our code on.  I think they claimed POSIX
compatibility; hollow laugh!  It was more like 1970's compatibility.  It
had 14-character file names, the shell and utilities regularly
core-dumped when doing ordinary work, everything had built-in random
undocumented line length limits and file size limits and such (which was
also true in V7 -- that's one thing Richard Stallman insisted on fixing
in every GNU utility; see the GNU Coding Standards).

Our GNU compiler tools ran everywhere, they hosted and bootstrapped on
everything.  Everything except QNX.  Shell scripts and makefiles that
worked on a hundred other UNIX systems were impossible to get working on
QNX.  I think we reported dozens of QNX bugs to the vendor, most of which
never got fixed.

Perhaps somewhere under all that crud there was some kind of "fast
microkernel", but you couldn't prove it by me.  By the time it got to
user code, the only thing it was fast at was failing.  We were trying to
do real work on it, and gave up after some engineers turned the air blue
with incredulous exclamations.  I think we ended up cross-compiling the
GNU compilers for it, from some sane system.  They still had to fix a
bunch of bugs in their libraries that we had to link with.

I realize this flame is not about microkernels.  But perhaps if they had
spent less time optimizing cache hits in the microkernel, the rest of
their system wouldn't have been shot full of obvious holes.

	John

Re: [TUHS] QNX

[Robert Brockway]

On Mon, 8 Feb 2021, John Gilmore wrote:

> Wait, are we talking about the same operating system called QNX?

Hi John.  I found your comment really interesting.  I have less experience 
with QNX than you do but I do have a long-standing interest in OS design 
and found it interesting from that perspective.

QNX is a high performance real-time OS that has run critical 
infrastructure for decades.  Notably it's been used to run nuclear power 
stations in many countries.

Usage may have declined in recent years but in the vintage you're 
discussing (90s) QNX would have been widely used in critical 
infrastructure.  I contracted to an electricity provider about 8 or 9 
years ago and QNX was definitely still there.

Looks like BlackBerry now own QNX and the OS is still out there keeping 
critical stuff running.

For the record I am aware that microkernels are not intrinsically slow and 
I think they can offer significant advantages.  MINIX 3 is an interesing 
design, pity about the name.

Cheers,

Rob

Re: [TUHS] QNX

[Nemo Nusquam]

On 09/02/2021 06:03, Robert Brockway wrote (in part):
> Looks like BlackBerry now own QNX and the OS is still out there 
> keeping critical stuff running.
According to their website, they are in 175 million vehicles (and a 
bunch of other things).

N.

Re: [TUHS] QNX

[Jose R Valverde via TUHS]

My experience was that old QNX (the one that was distributed on a floppy) was certainly wanting, however, the newer one, the one whose source was community open during the 90s and part of the 2000s (if I remember well) was pretty solid and standard. I ported a (significant) number of complex packages to it and made distribution packages without any problem. BTW, it was far advanced, making heavy use of Union file systems (sorta like the modern Snaps of Ubuntu) and the development tools were pretty powerful and comfy to use.

Then it switched hands and the source was closed again. Which was a pity. I still cherish my copies of the source.




En martes, 9 de febrero de 2021 19:25:29 CET, Nemo Nusquam <cym224@gmail.com> escribió: 





On 09/02/2021 06:03, Robert Brockway wrote (in part):
> Looks like BlackBerry now own QNX and the OS is still out there 
> keeping critical stuff running.
According to their website, they are in 175 million vehicles (and a 
bunch of other things).


N.

Re: [TUHS] QNX

[Larry McVoy]

On Mon, Feb 08, 2021 at 11:42:34PM -0800, John Gilmore wrote:
> Andrew Warkentin <andreww591@gmail.com> wrote:
> > A lot of people still seem to believe that microkernels are inherently
> > slow, even though fast microkernels (specifically QNX) predate the
> > slow ones by several years.
> 
> Wait, are we talking about the same operating system called QNX?
> 
> We had a customer at Cygnus in the 1990s (perhaps QNX itself) who wanted
> us to port the GNU compilers to it.  It was the slowest, buggiest system
> we ever tried to run our code on.  I think they claimed POSIX
> compatibility; hollow laugh!  

Has to be a different system.  The QNX I ran on could handle a bunch of
users on terminals on a 286.  But that was pre-POSIX, maybe the POSIX
stuff was crap, I wasn't using it then.