Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 May 2024 13:35:18 +0200
From:      Tomek CEDRO <tomek@cedro.info>
To:        henrichhartzer@tuta.io
Cc:        Freebsd Arch <freebsd-arch@freebsd.org>
Subject:   Re: Disabling COMPAT_FREEBSD4/5/6/7/9 in default kernel configurations
Message-ID:  <CAFYkXjnVHPf0M9LcFqPgZBfv=OKsYGVa-3C=C%2B_wPeNdxeZ%2Bnw@mail.gmail.com>
In-Reply-To: <NxZrrMD--3-9@tuta.io>
References:  <NxZrrMD--3-9@tuta.io>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 11, 2024 at 1:38=E2=80=AFAM <henrichhartzer@tuta.io> wrote:
> Hi everyone,
> Warner suggested that I run this by the list. In 2018, a bug report was m=
ade for disabling COMPAT_FREEBSD4/5/6/7/9 (there's no 8). 6 years later, I =
imagine this would be as good of a time as any to do this if there's no obv=
ious problems doing so.
> Here's the bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=
=3D231768
> And a pull request in the spirit of the original patch: https://github.co=
m/freebsd/freebsd-src/pull/1228
> I imagine if this sounds like a good idea, it would land in 15.0. Users c=
ould always recompile kernels with the old ABI functionality as needed. I f=
eel like we're all a little curious if anything still uses this, and making=
 this kind of change is probably the best way to find out.
> In my opinion, if all goes well, it may be wise to remove the old code in=
 the next major version. Could do the full list, or just FreeBSD 4 and 5 co=
mpatibility, for instance. Barring notable negative feedback, of course.
> There were some concerns about Rust, but it sounds like it uses (or used?=
) FreeBSD 10.X features, which this patch does not remove. On that topic: h=
ttps://github.com/rust-lang/rust/issues/89058
> Long term, it might be a good idea to enable support for EOL-1, and maybe=
 remove code for EOL-2, of course a less aggressive policy is also possible=
 (EOL-2 and EOL-3?). Getting out of the single digit FreeBSD versions shoul=
d be a good start, though!
> Appreciate any feedback on this and hopefully we can reach some kind of c=
onsensus on how to proceed in 2024.
> Thank you!
> -Henrich

One question: What are the benefits?

Having a clear list of pros and cons would result in more conscious decisio=
n :-)

Just to make sure - you are talking about changing the defaults in
GENERIC not removing the code? Because this part "it may be wise to
remove the old code in the next major version" sounds terrifying.
There was an idea recently to remove old audio card drivers.. I am
sure that made retro folks happy ;-)

There are still binary packages out there built on older FreeBSD
releases that would not work after that change (i.e. AnyDesk client
was built on 11.2 and works fine on 13 and 14). All those packages
will stop working.

Version References:
  required from libgcc_s.so.1:
    0x0b792650 0x00 10 GCC_3.0
  required from libthr.so.3:
    0x077a28b0 0x00 08 FBSD_1.0
  required from librt.so.1:
    0x077a28b0 0x00 07 FBSD_1.0
  required from libcxxrt.so.1:
    0x08922974 0x00 11 GLIBCXX_3.4
    0x056bafd3 0x00 05 CXXABI_1.3
  required from libm.so.5:
    0x077a28b0 0x00 04 FBSD_1.0
  required from libc.so.7:
    0x077a28b1 0x00 09 FBSD_1.1
    0x077a28b3 0x00 06 FBSD_1.3
    0x077a28b0 0x00 03 FBSD_1.0
    0x077a28b2 0x00 02 FBSD_1.2

Also I think that instead adhering to modern trends with a lifespan
shorter than yogurt focus on functionality and self-compatiblity
should be (as always was in FreeBSD). Instead removing perfectly
working code maybe the current code could be fixed/improved in the
first place?

I have upgraded to 14.0 and my desktop is highly unreliable [1]. 14.1
is about to be rolled out.. does it fix the LinuxKPI / DRM problem?
Will 15 or 16 have non-problematic LinuxKPI / DRM? NO. Because we
adhered to constantly moving target with no solid foundations of the
Linux world. With no fallback alternative (scfb only provides basic
single monitor workstation with no multi-screen + rotation). So I will
soon have to roll back to 13. And today I hear another great idea to
remove backward compatibility wow what a wonderful world :D

Long story short: I think this is a really bad idea to remove backward
and self compatibility. I avoid Linux exactly for that reason.

Have a good day :-)
Tomek

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D276985

ps/2: I think questions list could provide broader audience :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFYkXjnVHPf0M9LcFqPgZBfv=OKsYGVa-3C=C%2B_wPeNdxeZ%2Bnw>