On 10/03/2026 21:23, Constantine A. Murenin wrote:
> On Tue, 10 Mar 2026 at 14:43, Nick Holland <nick@holland-consulting.net>
> wrote:
>
>> Every diff requested requires firing up external applications. That's a
>> lot
>> of load, even for a significantly more efficient application.
that's not the issue. the issue is not to process the same requests
twice. process once, keep in cache, sever instantly without processing.
this is how a very IO intensive systems usually work. you preload all
caches and serve only from caches. sometimes preloading runs for a
longer while, simply loading caches. then all that content is server
effortlessly without much load.
>> Those requests are still coming in. Yesterday, well over 90% of the
>> queries
>> we got were URLs from the old application. So by returning a 404 instead
>> of
>> firing up cvs, co, and/or rcsdiff every time a bot query comes in, we save
>> a
>> LOT of load on the system. That's a HUGE win.
>>
>> This win has enabled me to remove the IP filters, I've removed much of the
>> malicious request handling which was all justifiably highly unpopular and
>> (unfortunately) hurting some of the legitimate users. I hope to soo
>> the systems this application runs on to a fully redundant CARP pair (due to
>> the load, I had to "split" the cvsweb off to its own machine, so lost the
>> redundancy). Lots of "win" here.
>>
>> So...unless the OpenBSD developers request otherwise, I do think we will
>> not
>> be worrying about -- and in fact, actively discouraging -- the old URLs.
>> I get
but you can keep the old URLs in place and simply display different
results. again, prepare the compliance once, profit forever.
> You're literally just providing more inapplicable excuses for doing the
> wrong thing.
the problem is here a very particular kind of zeal and denial, not
necessarily Nick's, but one in general. note some of the response in the
cvs thread, "because we used it for 29 years", "because here we do
things differently", "because this is what we want"
the first step in fixing a problem is acknowledging, objectively, that
is exists.
here are the inconvenient absolutes:
1. you may use tools other than what's provided with openbsd, i.e. nginx
vs httpd
2. CVS is ancient.
3. CVS has no high performance web UI
as I wrote elsewhere, i happen to work on projects handling up to 10k
RPS during busy hours, in 1-2 servers setups. very high load scenarios
at the core have a very high performing core application. then caching,
load balancing, proxying, whatever else you do with that, is secondary.
the core system needs to deliver.
any, and i mean ANY stable improvement of version control should start
with re-considering of current version control system
the problem with bots and abuse will only get worse in the future. it is
never going away.
> If those broken bots continue requesting all the version-to-version diffs,
> just block those N*(N-1) diffs; noone cares about those.
>
> But why do you break http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/ and the
> like, too?
>
> You pretend that the new cvsweb is not actually "cvsweb", but yet it's stil
> ***cvsweb***.openbsd.org.
>
> Do you seriously think it's reasonable to break everyone's links simply
> because some backend somewhere has changed slightly?
a simple crawler run locally could simply collect all URLs and port them
into nginx's map and rewrite for future compatibility. not a difficult task.
> Because it is simply not reasonable in my book. A user visiting the site
> couldn't care less if it's written in Go or in Perl. They care about the
> CONTENT they came for.
this
> This whole issue should have taken less time to fix than this entire
> discussion we're having. Instead, somehow it's okay for everyone
> everywhere to deal with all these broken links everywhere simply because of
> some invalid justifications that do not even make any sense in the grand
> scheme of things. So far, you have not provided a single valid reason for
> breaking EVERY SINGLE LINK on the website.
this. the problem is also nonsensical. people scream "but we love CVS,
we used it for 29 years, we are never giving it up" but then at the same
time they say "all them links we had active for a decade dead? no
problem eh"
one or the other
the dark truth is this:
1. OpenBSD needs to move onto a better version control system, ideally
one with very high performing web UIs
2. the move needs to be smooth.
instead of wasting time on CVS keep it as it, and start working on a
parallel system to replace it soon. Ken can maybe help in Go with the move.
No comments:
Post a Comment