Re: Mtr prob request

On Tue, Feb 28, 2023 at 09:16:23AM +0100, Daniele B. wrote:
> Janne Johansson <icepic.dz@gmail.com> wrote:
> > # GPLv2+
> >
> > So this is why it would not be considered, even if someone wanted it in base.
> >
> > It is not a goal in itself to move stuff from ports to base.
>
> Thanks for the extended explanation too.
>
> This remind me two important stuff. The first is to not trust 100% software just because is
> the ports/packages and this should be enough worrisome. Second do not accept 3rd party
> requests to install packages that could compromise your system although source of requests
> appears "100%" clean.
******************************************************************************
It's always a good idea to look over the software you are about to install
before installing it, and even more so before allowing it to become something
that you rely on.

This includes looking at who wrote it, who maintains it, and what their
development style is.

Some open source software is developed in a controlled way, and some is
developed in a very ad-hoc and slap-dash way.

Just to take one example - software which doesn't have specific releases, but
just tells you to 'download the latest code from git', is always something I
am suspicious of. Firstly, it's lazy. Secondly, it means that there is much
less likely to be a sizeable base of users running the same code, which is
useful for testing. Thirdly, can I trust their git repository not to have
been compromised? I want a simple source tarball, that somebody at least
tested compiles successfully, with a hash of some sort that I can verify
against a difficult to compromise source, (public mailing list post, third
party website, etc). This takes effort. If a project doesn't want to make
that effort, what else are they potentially slacking on? And can it
negatively affect the stability of my machines?

OpenBSD is great in this regard. Releases are _very_ well organised, and
being able to plan upgrades around a 6 month release cycle is a major benefit.

Also, in _my_ experience, with software that _I_ use, (so other people's
experiences may be different), I've found that software licensed under the
GPL, or that has come from a source with a linux background, tends to be more
likely to suddenly want to pull in a whole new set of libraries as
dependencies after an upgrade. This seems to stem from the misguided idea
that writing new code to do foo when code already exists to do foo is a bad
thing. It's not. Especially if the existing foo requires 200 external
libraries just to toggle a few bits, and do something that could be done in
10 lines of well-written C.

Once again, OpenBSD scores well here. How many external libraries does smtpd
depend on? How many does httpd depend on? When you upgrade to OpenBSD 7.3,
are you likely to find an extra 200 Mb of libraries installed as part of base,
just because httpd added support for sending one new header?

No, of course not. None of the OpenBSD developers would support such a move.

And we can pretty much _rely_ on that. So you can make a commitment to
OpenBSD _now_ and your chances of getting burned some time in the future are
probably quite slim. (As long as we are talking about the _base_ system.)

The sudden extra dependencies required by new versions of software in ports
might include things that I don't want on my system. Or at least not on
particular production systems. At some point, some dependency of gstreamer
started to require rust, and this makes it difficult, (but not impossible), to
compile and use webkit without installing rust on the same system.

I've got nothing against rust particularly, but the rust compiler is written
in rust, so by default a source build is not truely from source, because you
need to download some pre-compiled binaries to bootstrap the compile process.

Last time I tried to build it starting from an ancient C version of the rust
compiler it wasted a lot of time.

All of this is a big part of why basically all of the new software that we
develop in house at Exotic Silicon is written from scratch. If I write
software during work time, I'm expected to justify any use of external
libraries, because we do not want to create a dependency on something that
we do not control.

I'm working on the UTF-8 support in the kernel right now. I need a font with
glyphs for at least some of the extra characters. I can't just pull any old
font off of a website and convert it to the right format for use in the kernel.
I'm expected to draw my own glyphs. Furthermore, I'm expected to write my
own font editor to boot, (which I did last Sunday, actually).

Other people mock this approach. But it works, and as far as I'm concerned
our software is better for it. Our website CMS runs fast on very low-spec
hardware. Why? Because it's about 2000 lines of tight C code, with ZERO
use of software from ports. We wrote our own fcgi handler, we didn't run to
the ports tree for one.

So the take away is this: don't be so quick to type 'pkg_add' without thinking
and doing some research first, if you want your OpenBSD system to stay as
trouble-free and easily upgradable as the base system is.

A lot of developers work very hard to maintain the ports tree, but it's a
massive task, and there isn't anywhere enough developer time to dedicate to it.