Hello Branden, G. Branden Robinson wrote on Wed, Sep 09, 2026 at 01:48:08AM -0500:
> It's unfortunate that a lot of FLOSS conferences simulate academic ones > so half-heartedly. They're happy to book rooms for people to stand up > and present slide decks, but they don't require the submission of formal > papers to put forth the same material with the additional rigor afforded > by the medium of hardcopy. > > In other words, FLOSS conferences often don't generate _proceedings_. This observation does seem to apply to BSD conferences. There are downsides - less rigour, harder to read up on the subject - and advantages - lower entry barrier in terms of time and professionalism required to participate. BSD projects tend to be relative short on people and working time, so proceedings would consume work also needed for further progress on the code, so it's a tradeoff. > Some people are in this field to learn things and solve problems. > Others are in it to climb social and economic ladders. That's probably true in any field, and rarely black and white. I suspect the "climbing" aspect to be more common in business and politics than in academia and free software, but it's certainly not unheard of in academia either. > Ingo Schwarze wrote: >> Occasionally, Krugman may even be be overdoing sparseness - >> for example, on slide 9, saying what "AC" and "MC" mean would >> hardly hurt. Alternating current? Master of ceremonies? <scratch> > Average cost and marginal cost. Oh yes, that absolutely makes sense, and confusing the two is indeed a common source of economic fallacies. :-/ > I reckon "AC" and "MC" are about as idiomatic to that discipline as > "DAG" is to computer science and software engineering. ;-) Now you make me feel really bad. :-D I had to look up what "DAG" is supposed to mean, and i suspect you mean "directed acyclic graph", but i'm not entirely sure. Even though the mandoc AST is of course a DAG... :) >> Oh, and slide 16 contains only a thematic map, without even a caption >> or legend. > I guess one has to check the recording of the speech to find out what he > was up to there! Probably. During some past BSD conferences, sound quality of recordings was really bad, which teams up poorly with frugal slides and lack of proceedings. > Talk given on the occasion of receiving a prize are frequently not > peer-reviewed, but play the role of "surveys" of the field, or, > sometimes, as opportunities for the figure thus awarded to try and > elevate a proposition into the discourse above what empirical > foundations can justify. Interesting observation. Maybe i'll look at some of your examples, but i'll refrain from commenting at this point, except for one comment. I do not object to a technical or scientific presentation also making a speculative or political point, as long as it is clearly labeled as such and not misrepresented as confirmed fact. It is quite easy to stray in that respect, because there is a psychological tendency to perceive one's own personal conclusions as sufficiently supported by at least some facts - it seems almost certain that i have strayed in that respect at least occasionally in the past, maybe even regularly. >> Regarding the on-topic parts (i may have missed some aspects due >> to the volume of the thread): >> >> * .BVL 1cm [...] >> Still, it is wise to not gratuitiously break compatibility - >> incompatible changes should deliver a clear benefit. >> Causing .BVL 1cm to fail hard might for example be a step too far. > I don't see any evidence that we're doing that. Today, I pushed a fix > for the formatting error Deri identified, and that fix will be in the > next groff 1.25 release candidate. > > https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=9cfe8d43a14e8eda6b0962409a2cc49f251b8911 Sounds good, i didn't mean to claim anything was deliberately broken here. The discussion of what was going on was complicated enough that i wasn't immediately sure how everything was related, and "Causing .BVL 1cm to fail" was merely an example of what i thought should not be done, not intending to claimit was. It now appears there were two entirely separate issues - the regression that you fixed (which broke .BVL 1c IIUC) - and my sloppiness using the bad syntax ".BVL 1cm" (but that never broke more than .BVL 1c IIUC). So that's probably settled now. >> * Changing the default margins in a formatter may happen from >> time to time, though it will of course make some old documents >> look ugly, in particular when the authors of these documents >> engaged in typographical fine-tuning. >> Nothing can be done about that, really. >> Sure, having defaults gratuitiously jump all over the place >> all the time would be ridiculous, but saying that no default >> can ever be changed would stymie progress. > ...and, for the fully fledged full-service package, anyone who has > tweaked their document to typeset _just so_ can specify their page > margins explicitly with requests and macro calls at the top of the > document. True, in this particular case, that would help. When you engage in typographical fine-tuning, there are countless other details that might change in the future, and trying to clamp them all down when writing the document is neither practical nor sufficient. I seems better for saving time and helping source readability to only sparingly restate defaults even when fine-tuning, and simply accept that an update of the formatter might require re-tuning some aspects. Yours, Ingo
