Rust, and resistance to it in some parts of the Linux community, has been in my feed recently. One undercurrent seems to be the notion that Rust is woke (and should therefore be rejected as part of culture wars).
I’m going to argue that Rust, the language, is woke. So the opponents are right, in that sense. Of course, as ever, dissing something for being woke is nasty and fascist-adjacent.
tl;dr: Your vote really counts!
Each vote in a UK General Election is worth maybe £100,000 - to you and all your fellow citizens taken together. If you really care about the welfare of everyone affected by actions of the UK government, then it’s worth that to you too.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ceb and I are members of the Derril Water Solar Park cooperative.
We were recently invited to vote on whether the coop should bid for a Contract for Difference, in a government green electricity auction.
We’ve voted No.
For a while ceb and I have wanted to contribute directly to green energy provision. This isn’t really possible in the mainstream consumer electricy market.
Mainstream electricity suppliers’ “100% green energy” tariffs are pure greenwashing. In a capitalist boondoogle, they basically “divvy up” the electricity so that customers on the (typically more expensive) “green” tariff “get” the green electricity, and the other customers “get” whatever is left. (Of course the electricity is actually all mixed up by the National Grid.) There are fewer people signed up for these tariffs than there is green power generated, so this basically means signing up for a “green” tariff has no effect whatsoever, other than giving evil people more money.
About a year ago we heard about Ripple. The structure is a little complicated, but the basic upshot is:
Ripple promote and manage renewable energy schemes. The schemes themselves are each an individual company; the company is largely owned by a co-operative. The co-op is owned by consumers of electricity in the UK., To stop the co-operative being an purely financial investment scheme, shares ownership is limited according to your electricity usage. The electricity is be sold on the open market, and the profits are used to offset members’ electricity bills. (One gotcha from all of this is that for this to work your electricity billing provider has to be signed up with Ripple, but ours, Octopus, is.)
It seemed to us that this was a way for us to directly cause (and pay for!) the actual generation of green electricity.
So, we bought shares in one these co-operatives: we are co-owners of the Derril Water Solar Farm. We signed up for the maximum: funding generating capacity corresponding to 120% of our current electricity usage. We paid a little over £5000 for our shares.
The UK has a renewable energy subsidy scheme, which goes by the name of Contracts for Difference. The idea is that a renewable energy generation company bids in advance, saying that they’ll sell their electricity at Y price, for the duration of the contract (15 years in the current round). The lowest bids win. All the electricity from the participating infrastructure is sold on the open market, but if the market price is low the government makes up the difference, and if the price is high, the government takes the winnings.
This is supposedly good for giving a stable investment environment, since the price the developer is going to get now doesn’t depends on the electricity market over the next 15 years. The CfD system is supposed to encourage development, so you can only apply before you’ve commissioned your generation infrastructure.
Ripple recently invited us to agree that the Derril Water co-operative should bid in the current round of CfDs.
If this goes ahead, and we are one of the auction’s winners, the result would be that, instead of selling our electricity at the market price, we’ll sell it at the fixed CfD price.
This would mean that our return on our investment (which show up as savings on our electricity bills) would be decoupled from market electricity prices, and be much more predictable.
They can’t tell us the price they’d want to bid at, and future electricity prices are rather hard to predict, but it’s clear from the accompanying projections that they think we’d be better off on average with a CfD.
The documentation is very full of financial projections and graphs; other factors aren’t really discussed in any detail.
The rules of the co-op didn’t require them to hold a vote, but very sensibly, for such a fundamental change in the model, they decided to treat it roughly the same way as for a rules change: they’re hoping to get 75% Yes votes.
The reason we’re in this co-op at all is because we want to directly fund renewable electricity.
Participating in the CfD auction would involve us competing with capitalist energy companies for government subsidies. Subsidies which are supposed to encourage the provision of green electricity.
It seems to us that participating in this auction would remove most of the difference between what we hoped to do by investing in Derril Water, and just participating in the normal consumer electricity market.
In particular, if we do win in the auction, that’s probably directly removing the funding and investment support model for other, market-investor-funded, projects.
In other words, our buying into Derril Water ceases to be an additional green energy project, changing (in its minor way) the UK’s electricity mix. It becomes a financial transaction much more tenously connected (if connected at all) to helping mitigate the climate emergency.
So our conclusion was that we must vote against.
Many people seem to be pretending that the pandemic is over. It isn’t. People are still getting Covid, becoming sick, and even in some cases becoming disabled. People’s plans are still being disrupted. Vulnerable people are still hiding.
Conference organisers: please make robust Covid policies, publish them early, and enforce them. And, clearly set expectations for your attendees.
Attendees: please don’t be the superspreader.
( Rant )
tl;dr: Please vote in favour of the Debian Social Contract change, by ranking all of its options above None of the Above. Rank the SC change options above corresponding options that do not change the Social Contract.
Vote to change the SC even if you think the change is not necessary for Debian to prominently/officially provide an installer with-nonfree-firmware.
I’m addressing myself primarily to the reader who agrees with me that Debian ought to be officially providing with-firmware images. I think it is very likely that the winning option will be one of the ones which asks for an official and prominent with-firmware installer.
However, many who oppose this change believe that it would be a breach of Debian’s Social Contract. This is a very reasonable and arguable point of view. Indeed, I’m inclined to share it.
If the winning option is to provide a with-firmware installer (perhaps, only a with-firmware installer) those people will feel aggrieved. They will, quite reasonably, claim that the result of the vote is illegitimate - being contrary to Debian’s principles as set out in the Social Contract, which require a 3:1 majority to change.
There is even the possibility that the Secretary may declare the GR result void, as contrary to the Constitution! (Sadly, I am not making this up.) This would cast Debian into (yet another) acrimonious constitutional and governance crisis.
The simplest answer is to amend the Social Contract to explicitly permit what is being proposed. Holger’s option F and Russ’s option E do precisely that.
Amending the SC is not an admission that it was legally necessary to do so. It is practical politics: it ensures that we have clear authority and legitimacy.
I think prominently distributing an installer that can work out of the box on the vast majority of modern computers would help Debian advance our users’ freedom.
I see user freedom as a matter of practical capability, not theoretical purity. Anyone living in the modern world must make compromises. It is Debian’s job to help our users (and downstreams) minimise those compromises and retain as much control as possible over the computers in their life. Insisting that a user buys different hardware, or forcing them to a different distro, does not serve that goal.
I don’t really expect to convince anyone with such a short argument, but I do want to make the point that providing an installer that users can use to obtain a lot of practical freedom is also, for many of us, a matter of principle.
I have just disconnected from irc.freenode.net for the last time. You should do the same. The awful new de facto operators are using user numbers as a public justification for their behaviour. Specifically, I recommend that you:
Note that mentioning libera in the channel topic of your old channels on freenode is likely to get your channel forcibly taken over by the new de facto operators of freenode. They won't tolerate you officially directing people to the competition.
I did an investigation and writeup of this situation for the Xen Project. It's a little out of date - it doesn't have the latest horrible behaviours from the new regime - but I think it is worth pasting it here:
Message-ID: <24741.12566.639691.461134@mariner.uk.xensource.com> From: Ian Jackson <iwj@xenproject.org> To: xen-devel@lists.xenproject.org CC: community.manager@xenproject.org Subject: IRC networks Date: Wed, 19 May 2021 16:39:02 +0100 Summary: We have for many years used the Freenode IRC network for real-time chat about Xen. Unfortunately, Freenode is undergoing a crisis. There is a dispute between, on the one hand, Andrew Lee, and on the other hand, all (or almost all) Freenode volunteer staff. We must make a decision. I have read all the publicly available materials and asked around with my contacts. My conclusions: * We do not want to continue to use irc.freenode.*. * We might want to use libera.chat, but: * Our best option is probably to move to OFTC https://www.oftc.net/ Discussion: Firstly, my starting point. I have been on IRC since at least 1993. Currently my main public networks are OFTC and Freenode. I do not have any personal involvement with public IRC networks. Of the principals in the current Freenode dispute, I have only heard of one, who is a person I have experience of in a Debian context but have not worked closely with. George asked me informally to use my knowledge and contacts to shed light on the situation. I decided that, having done my research, I would report more formally and publicly here rather than just informally to George. Historical background: * Freenode has had drama before. In about 2001 OFTC split off from Freenode after an argument over governance. IIRC there was drama again in 2006. Significant proportion of the Free Software world, including Debian, now use OFTC. Debian switched in 2006. Facts that I'm (now) pretty sure of: * Freenode's actual servers run on donated services; that is, the hardware is owned by those donating the services, and the systems are managed by Freenode volunteers, known as "staff". * The freenode domain names are currently registered to a limited liability company owned by Andrew Lee (rasengan). * At least 10 Freenode staff have quit in protest, writing similar resignation letters protesting about Andrew Lee's actions [1]. It does not appear that any Andrew Lee has the public support of any Freenode staff. * Andrew Lee claims that he "owns" Freenode.[2] * A large number of channel owners for particular Free Software projects who previously used Freenode have said they will switch away from Freenode. Discussion and findings on Freenode: There is, as might be expected, some murk about who said what to whom when, what promises were made and/or broken, and so on. The matter was also complicated by the leaking earlier this week of draft(s) of (at least one of) the Freenode staffers' resignation letters. Andrew Lee has put forward a position statement [2]. A large part of the thrust of that statement is allegations that the current head of Freenode staff, tomaw, "forced out" the previous head, christel. This allegation is strongly disputed by by all those current (resigning) Freenode staff I have seen comment. In any case it does not seem to be particularly germane; in none of my reading did tomaw seem to be playing any kind of leading role. tomaw is not mentioned in the resignation letters. Some of the links led to me to logs of discussions on #freenode. I read some of these in particular[3]. MB I haven't been able to verify that these logs have not been tampered with. Having said that and taking the logs at face value, I found the rasengan writing there to be disingenuous and obtuse. Andrew Lee has been heavily involved in Bitcoin. Bitcoin is a hive of scum and villainy, a pyramid scheme, and an environmental disaster, all rolled into one. This does not make me think well of Lee. Additionally, it seems that Andrew Lee has been involved in previous governance drama involving a different IRC network, Snoonet. I have come to the very firm conclusion that we should have nothing to do with Andrew Lee, and avoid using services that he has some effective control over. Alternatives: The departing Freenode staff are setting up a replacement, "libera.chat". This is operational but still suffering from teething problems and of course has a significant load as it deals with an influx of users on a new setup. On the staff and trust question: As I say, I haven't heard of any of the Freenode staff, with one exception. Unfortunately the one exception does not inspire confidence in me[4] - although NB that is only one data point. On the other hand, Debian has had many many years of drama-free involvement with OFTC. OFTC has a formal governance arrangement and it is associated with Software in the Public Interest. I notice that the last few OFTC'[s annual officer elections have been run partly by Steve McIntyre. Steve is a friend of mine (and he is a former Debian Project Leader) and I take his involvement as a good sign. I recommend that we switch to using OFTC as soon as possible. Ian. References: Starting point for the resigning Freenode staff's side [1]: https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409 Andrew Lee's side [2]: https://gist.github.com/realrasengan/88549ec34ee32d01629354e4075d2d48 [3] https://paste.sr.ht/~ircwright/7e751d2162e4eb27cba25f6f8893c1f38930f7c4 [4] I won't give the name since I don't want to be shitposting.
master for the default git branch. Regardless of the etymology (which is unclear), some people say they have negative associations for this word, Changing this upstream in git is complicated on a technical level and, sadly, contested.
But git is flexible enough that I can make this change in my own repositories. Doing so is not even so difficult.
So:
I intend to rename master to trunk in all repositories owned by my personal hat. To avoid making things very complicated for myself I will just delete refs/heads/master when I make this change. So there may be a little disruption to downstreams.
I intend make this change everywhere eventually. But rather than front-loading the effort, I'm going to do this to repositories as I come across them anyway. That will allow me to update all the docs references, any automation, etc., at a point when I have those things in mind anyway. Also, doing it this way will allow me to focus my effort on the most active projects, and avoids me committing to a sudden large pile of fiddly clerical work. But: if you have an interest in any repository in particular that you want updated, please let me know so I can prioritise it.
Why "trunk"? "Main" has been suggested elswewhere, and it is often a good replacement for "master" (for example, we can talk very sensibly about a disk's Main Boot Record, MBR). But "main" isn't quite right for the VCS case; for example a "main" branch ought to have better quality than is typical for the primary development branch.
Conversely, there is much precedent for "trunk". "Trunk" was used to refer to this concept by at least SVN, CVS, RCS and CSSC (and therefore probably SCCS) - at least in the documentation, although in some of these cases the command line API didn't have a name for it.
So "trunk" it is.
People are (finally!) starting to replace "blacklist" and "whitelist". Seriously, why has it taken everyone this long?
I have been using "blocklist" and "passlist" for these concepts for some time. They are drop-in replacements. I have also heard "allowlist" and "denylist" suggested, but they are cumbersome and cacophonous.
Also "allow" and "deny" seem to more strongly imply an access control function than merely "pass" and "block", and the usefulness of passlists and blocklists extends well beyond access control: protocol compatibility and ABI filtering are a couple of other use cases.
