[follow-ups should probably go to -project, but I'm not setting my headers to try to force that]
At 2024-01-24T16:57:06+0100, Simon Josefsson wrote:
> One could equally well make the argument that distributors should care
> about the Go/Rust ecosystems, and make whatever changes needed in
> order to support them. Those changes are what I'm trying to explore
> here.
Exploration is one thing; advocacy is another. Please be clear which
role you're taking in any given discussion. (If you switch hats
midstream, be explicit about it).
[rearranging]
> Speaking as a C person (I know little about Go/Rust), getting stable
> ABIs, dynamic linking [...] right is not simple, and we've been
> working on that for 20+ years consuming plenty of human resources on
> the way.
That's true, but think about the goal that stable ABIs and dynamic
shared objects achieve: software modularity in the field at runtime. I
trust that I don't have to argue the benefits of modular design to any
even slightly experienced software developer; its benefits have been
understood for about fifty years.
(Just to get this on the record, and for obligatory technical content:
I've studied Go a little and Rust a bit more. I think that, _as
languages_, they're likely both superior to C in most respects. [If you
want to visualize PDP-11 assembler output and stack layout as you code,
both are likely ill-suited to the purpose, as standard C itself
increasingly is.] In any case they are well worth a software
professional's time to look at, in my opinion. That doesn't mean you
have to endorse their adoption.)
> and security upgrades
And there's the payoff of dynamic modularity, if you will.
If the origin of a statically linked object, whatever its language of
implementation, is not on the ball _for any reason_, the exposure of a
security vulnerability in it or anything upon which it depends expands a
temporal window of attack on affected systems. We _know_ that certain
actors in the global IT sector hoard undisclosed vulnerabilities for
deployment later, at opportune times for extortion or data exfiltration
against targets of interest.
Next, consider some of the reasons why the origin of a statically linked
object might come "off the ball". Maybe they got fired or laid off.
Maybe they burned out. Maybe they died. Maybe they've been told the
project is supposed to become part of their "20% time"[sic]. Maybe it's
just "not a priority" to their employer. Maybe they had a baby or
finally went on that long-planned vacation to a tropical island.
If you've worked in Big IT you know that you can predict that when your
business unit gets a new director, _you_ get a new direction. Directors
and other senior managers justify their huge salaries and benefit
packages by being "impactful", and one reliable way to be "impactful" is
by handing down dramatic decrees. (All of the top capitalists are
gamblers; one can easily perceive this in their personalities and
rhetoric.) At one place I worked such a thing happened twice in less
than a year, I think. We were going to "drop all Linux" and rebase
everything on FreeBSD. Then that director departed the company and
FreeBSD was out the window--back to Linux.[1]
Worse, when any of these disruptions happens to the origin of a module
that employs static linking, it can take an indefinite amount of time to
_find out_ that such has even taken place. So its user community may
lose time while it politely waits for their upstream to check in from
vacation or whatever, because they don't want to be rude, or seen as
hijacking the project, or similar. And even that assumes that the right
people in the community have sufficient expertise to reasonably
approximate the usual construction and release procedures, which can
vary not just in the technology of the implementation system, but in the
hosting/development site.
Consider the motivations and pressures that professionalized, corporate
software is developed under. Any cost of development that can be
externalized experiences an unrelenting force in that direction.
An economic profit is the difference between the revenue received from
sales and the explicit costs of producing its goods and services, as
well as any opportunity costs.[2]
Opportunity costs are an interesting subject.[3] They are often
difficult or even impossible to measure. In business culture, they are
often therefore utterly neglected, even when they are known to exist.
This is why firms pollute, know they pollute, deny to the public that
they pollute, argue with everyone who challenges them about the
consequences of their pollution, and ultimately attempt to escape
liability for their subjection of others--ultimately, human beings and
the environment generally--to their negative externalities. The
emphasis on profit and a desire by the wealthiest in society to preserve
the prevailing economic system is also why very concept of negative
externalities is under-emphasized or omitted entirely from economics
education at the lower levels. (Eventually, in tertiary education, it's
dealt with reasonably frankly, since people acquiring an MBA or majoring
in economics are demonstrably staking their livelihoods on maintenance
of the status quo--a fact not all of them may appreciate at first. They
may have to be taught by getting their papers suddenly rejected, being
passed over for promotion, or missing out on a sweet junket with the Big
Boss and the favorites being teased with prospects of succession.)
What force can work against this reflexive, instinctive externalization
of costs? We briefly considered it above, and we live it.
Community. Community is a concept that at best fits uncomfortably with
rudimentary economic analysis (the variety favored by decision-makers in
most firms). In a non-iterated game of Prisoner's Dilemma, a
profit-maximizing actor will defect every time.[4] In real life, we
frequently encounter our economic counterparties multiple times, which
can counterbalance the tendency of profit-maximizing strategies to
sociopathy. On the other hand, the legal frameworks of societies often
do much to establish or reinforce the capacity of the well-heeled to act
with impunity. An important development in this area was the concept of
"limited liability", now universally applied to publicly traded firms.
(It is worth remembering that the concept of the firm has its roots in
royally chartered companies, which came into being before the principles
of absolute monarchy and the divine right of kings were not yet dead.)
A consequence of this innovation is that decision makers seldom face
negative consequences even for grievously harmful actions; this low risk
to themselves creates what is known, in terminology quaint to the ears
of the ruling class, as a "moral hazard".[5]
To return to specifics and technology, consider that Go and Rust were
both developed nearly exclusively by people working for firms.[6] Yes,
dynamic linking and maintenance of stable ABI promises are hard. That
means they cost. But static linking and volatile ABIs also have a
cost--an opportunity cost. If that cost is both (1) hard to measure and
(2) will be borne by economic actors outside your firm, the obviously
rational choice is to not bother with dynamic linking and stable ABIs.
You make it "a 'you' problem, not a 'me' problem." When you hear
language like this, overtly or implicitly, you are hearing a person
express a disavowal or even repudiation of community with you.
What our community _can_ do is identify ways of driving negative
externalities back toward those who are imposing them, making them
internal. This could be perceived as an opportunity cost in the form
already proposed in this thread--just not bothering with software
ecosystems that are dependent on this model. Yes, there is a risk that
Debian could "make itself irrelevant", at least to those sectors for
which rapid application development with Go and Rust (and Python and
NodeJS?) are important. Maybe that's a trade-off, the classic "hard
choice". But such a statement of position might have more impact than
one suspects. Remember again what motivates senior decision makers in
firms: "making an impact". Attenuating the uptake of an "impactful new
technology" is a threat that such people understand viscerally. Such
people have large amounts of disposable income that they use to play
stock markets. Observe how shareholders (largely algorithmic trading
agents, I fear) "punish" firms that don't merely fail to end a fiscal
quarter in the black, but which fail to grow _as much_ as projected, or
whose rate of growth inflects. The Masters of the Universe[11]
recognize no growth curve but the exponential, and any asset that isn't
exponentially growing in value is, to them, failing. Bitcoiners emulate
the mentalities of those they admire, the already wealthy.[12] That is
why one of their mantras is "number go up!".
If I'm right, then it won't actually take much to bend that curve, to
shift adoption rates below projections. And do these people ever hate
coming in below projections.
Debian is still big and influential. Our capacity to make a significant
"impact" should not be dismissed. We must acknowledge that downstream
distributions might not make the same choice. For instance, Ubuntu's
own decision makers may have greater sympathy with the attitudes of the
"Masters of the Universe", for reasons obvious and less so.
But when the security wheels fall off the cart of an important
statically constructed module that has been quietly abandoned by its
developer--and I assert that such an incident is inevitable--it need not
be Debian that bears the costs thus externalized.
Regards,
Branden
[1] This wasn't an entirely negative experience for me, personally. I
got to (along with dozens of others) take some of Kirk McKusick's
presumably expensive FreeBSD training on the company dime in person.
I learned a lot, gained new respect for the system (if not the
anti-copyleft licensing invective of some of its community), and
broadened my horizons. But the whipsawing in tooling and mission
was not productive in the workplace.
[2] https://www.investopedia.com/terms/e/economicprofit.asp
[3]
https://press.princeton.edu/books/hardcover/9780691154947/economics-in-two-lessons
John Quiggin is a terrific writer on economics. Read anything by
him you can get your hands on.
[4] https://www.youtube.com/watch?v=BOvAbjfJ0x0
[5] https://hbr.org/2016/10/a-short-history-of-golden-parachutes
[6] At least initially. Google still steers Go unilaterally as far as I
know. Rust's story is murkier, with its original developer having
long ago detached from the project. Rust may now nominally be a
community-driven effort, but it appears to me it may now in fact be
mono- or oligopolistically administered.[7] A key piece of evidence
supporting this inference, in my opinion, was the retraction of
Jean-Heyd Meneide's invited keynote speech at last year's
RustConf.[8] Despite much alarm and concern in the FLOSS community
generally, a public apology and an acknowledgement not just of the
bad optics but the bad governance this incident revealed, to my
knowledge no disclosure has been made of whose hand was on the
dagger that went into Meneide's metaphorical back. A couple of
people who were downstream of the ultimate decision effused remorse,
but tellingly, these sad explanations fell conspicuously short of a
root-cause analysis. That lack of disclosure suggests to me a
coziness and _strongly_ mutually conciliatory attitude among the
effective governing membership.[9] Or, worse, the hand belongs to a
single dominant figure, and the charter of the remainder of the
governing body, whatever might be written down, is understood to be
ratification of the leader's decisions and protection of that leader
from embarrassment.[10]
[7] ...much as the Linux kernel is by the platinum members of the Linux
Foundation.
[8] https://fasterthanli.me/articles/the-rustconf-keynote-fiasco-explained
[9] There's an exquisitely apropos quotation from the series _The Wire_
that fits the alternative approach to collective embarrassment, but
unfortunately it is NSFW. For those familiar with the show, as I
recall it's uttered in the mayor's office after Hamsterdam makes the
newspapers.
[10] The miniseries _Chernobyl_ also offers insight here. I'll
paraphrase for adaptation to this context. "What you are proposing
is that [the committee] humiliate a [person] that is obsessed with
not being humiliated." When you see this sort of ethical priority
operating in your work or personal life, know that you are in a
toxic environment.
[11] https://www.theguardian.com/business/2002/mar/24/enron.theobserver
[12] I really can't thank Ian Jackson enough for bringing David Gerard's
_Attack of the 50-Foot Blockchain_ to my attention. If John
Quiggin is too dry for you, try this book first. You'll laugh,
you'll cry, you'll vomit at all the stupidity and greed that Gerard
documents and coldly evaluates.
signature.asc
Description: PGP signature
