Samuel wrote:
David Uhden Collado <[email protected]> wrote:
Who would've thought that software that hasn't been updated in two
decades will have problems with modern workflows?
I maintain my own fork of OpenBSD's fvwm, so if you want to send a
patch, I'd be happy to take it. I don't personally use fvwm, but I don't
like seeing my own work - or other people's - thrown away, so I'm
keeping it alive.
[...]
passive-aggressive much?
On Fri, Oct 2, 2026 at 11:20\xe2\x80\xafAM David Uhden Collado <daviduhden@gmail
.com> wrote:
[...]
The version of fvwm in the base system is not being actively maintained.
What I did in my fork was improve its memory handling to make it safer,
This fork has been discussd on the tech@ list:
https://marc.info/?t=176142471200001&r=1&w=2
David is tripping over his own feet somehow, and the copyright ownership
of his work cannot be ascertained.
Well, with that kind of reasoning, I think they should remove Clang/LLVM
from the base system because of LLVM's policy on AI use [1] and write
their own compiler instead, since at this point you can no longer
reliably know which code was written by a human and which was generated
by a machine.
It is a blatant double standard. By the same logic, they would also have
to remove Linux DRM code and tmux.
I am not even going to get into ports that the project builds and
distributes, because the situation would look even more ridiculous.
References:
[1] https://llvm.org/docs/AIToolPolicy.html
On the other hand, I actually think it is a good policy. When I made my
first proposed changes to FVWM, I had not tested them thoroughly enough.
Later, I found more problems and fixed them. It was all done through
trial and error. I knew what I did not like and what I wanted to change;
the main goal was simply to lay the groundwork so the fork would be
viable and would not keep inheriting technical debt from the past.
That is also broadly consistent with the human-in-the-loop approach
adopted explicitly by LLVM and, in practice, by Firefox: AI-generated
code is allowed, but the human contributor is expected to review it,
understand it, be able to explain it, and take responsibility for what
they submit.
(Yeah, I'm nobody; I just want to show the "other side of the issue,"
for the record.)
make fairly extensive use of OpenBSD's security features, and fix the
bugs that were already documented. I also rewrote the components that
were still under the GPL, but that's secondary; it's just to bring this
software into compliance with copyright policy, which stopping updates
didn't resolve.
I have not looked at the rest of the Xenocara applications, and I do not
want to. I did this mostly because I saw something that was wrong,
became obsessed with fixing it, and now I do not want to keep going and
fall into the kind of obsessive loop that is typical with OCD.
Otherwise, I would probably end up with a fork of every piece of
third-party software I run on OpenBSD, which, frankly, I am often
tempted to do and think is how it should be handled. The project
shouldn't spend time and energy compiling garbage that is not properly
maintained and properly integrated into the system.
--
"Take my yoke on you and learn from me, for I am gentle and humble in
heart; and you will find rest for your souls."
