I am looking for people to help install new political notes on the site. If you'd like to help me in this way, please write to rms at gnu period org.
Roughly 10,000 people die in London each year from air pollution, much of it from diesel engines.
The UK government attacks everyone's freedom, supposedly to reduce the already tiny danger of terrorism. But terrorists would find it exceedingly hard to kill even 1% as many people as the diesels do.
Britons should demand that the government end to massive surveillace and focus on the greater danger of cars. But this lesson is not limited to Britain.
How many thousands do diesels kill every year in France? I don't know, but it must be thousands. So why have a "state of emergency" that tramples human rights supposedly to protect against the secondary danger of terrorists, instead of against car companies?
A US thug that is dismissed for misconduct can easily get another job as a thug, because there is no firm system to prevent it.
Many states do absolutely nothing, when thugs are fired for violence against the public, to stop them from getting hired somewhere else.
Now that El Niño has ended, 2017 may not set a new heat record. Denialists are likely to start spreading the myth that "global heating stopped in 2016."
The FCC's weak ISP privacy rules are too much for the trumpets. They plan to eliminate them.
ISPs should respect customers' privacy by not taking any note of their traffic, except pursuiant to a specific court order.
The data was provided in anonymized form, but Mastercard could reidentify the data by correlating it with other data.
He says privatization "seem to work better", but better for whom? Perhaps for his future employers, some years from now.
China has become dominant in the manufacturing of renewable energy generation.
China is making a big investment, while its potential competitors are dominated by planet-roasters and denialists.
Thugs in Alabama killed Robert Earl Lawrence for refusing to show identification. All he did was refuse.
He brought a stray dog to an animal shelter, but refused to show a driver's license, so the staff called the thugs. How gratuitous. They could just as easily said, "We won't take the dog from you without your identification, so just let it run loose outside the door." It would have been stupid, but no more stupid than what they did.
While attempting to travel to the future to get a copy of Portal 3. I accidentally traveled to alternate-1987 and obtained a copy of Portal 1 for the Apple II!
In actuality I originally just planned to do the end credits. But the Apple II high-res mode has the perfect Aperture Science orange and blue colors, and one thing led to another...
If you use TweetDeck on a desktop, you can set up a "Team" where an employee has their own password, and has the ability to post to the business account, but does not have access to the password that can lock everyone else out.
But as far as I can tell, there's no way to do this on mobile. As they rolled out "teams" over two years ago, I assume they have no plans to fix this oversight.
I guess I could host my own access-controlled web page that allowed my employees to post text and images to a form, and then have it twit on the back end... but that would totally not work at all for video. (All of the social media apps resize the video locally first and then upload it in resumable chunks, and with good reason. You can't accomplish this sort of thing without a native app.)
In my last blog post I expressed my severe disappointment with the gap between the Rust language in theory (as I had read about it) and the Rust language in practice, as I encountered it when I actually tried to write something in it.
Part of what I hoped for was a constructive response from the Rust community. I think I got that. Amidst the expected volume of flamage from rather clueless Rust fanboys, several people (I’m going to particularly call out Brian Campbell, Eric Kidd, and Scott Lamb) had useful and thoughtful things to say.
I understand now that I tested the language too soon. My use case – foundational network infrastructure with planning horizons on a decadal scale – needs stability guarantees that Rust is not yet equipped to give. But I’m somewhat more optimistic about Rust’s odds of maturing into a fully production-quality tool than I was.
Still, I think I see a problem in the assumptions behind Rust’s development model. The Rust community, as I now understand it, seems to me to be organized on a premise that is false, or at least incomplete. I fear I am partly responsible for that false premise, so I feel a responsibility to address it square on and attempt to correct it.
Technically, I greatly admire Rust’s crate system. I see its continuity with earlier experiments in the same general direction – Perl CPAN, Python Pip. But crates are easier to use than their predecessors and get more details right. The differences are evolutionary, but they matter – they add up to making crates a near ideal tool for enabling code re-use and a decentralized swarm attack on the design space around Rust.
It’s “let a thousand modules bloom”, and exactly the kind of approach I advocated in my foundational work on the open-source development model. I pushed hard in that direction back around the turn of the century because that’s what the times demanded; our main problem then was getting out from under overcontrolling practices that were holding back software engineering and serving both its craftsmen and its customers rather poorly.
Now, confronting a purer expression of those decentralist ideas than we then knew how to build, I worry that I may have encouraged a kind of utopianism – a belief that if we just cultivate enough decentralization and divergence of approach, good whole systems will just sort of coalesce out of the chaos without anyone having to make hard decisions.
But evolution doesn’t work that way. Ratcheting up adaptive fitness requires not just mutation but selective pressure. Alternatives need to be winnowed as well as generated. Markets (even reputation markets) have penalties as well as rewards – if you offer an inferior product, people won’t buy it and eventually you need to go do something else to survive.
Which brings me directly to what bothers me about the crate system and the sociology behind it – I don’t see any pruning. Worse, I don’t see much understanding of the need for it. A lot of Rustaceans don’t seem to grasp why, when the question is “where do I get feature X?” the answer “oh, there are 23 crates for that” is objectively terrifying.
How many of those crates are student exercises or plain junk? How do I tell which ones are still maintained? How do I audit for quality? How do I form expectations about which will still be maintained in ten years? How do I even find all the crates that might be relevant to my interests?
This isn’t a question that comes up so often with respect to (say) Python because Python has an effective form of curation – blessing things into the standard library, at which point their alternatives generally disappear. In effect, Python modules are quality-filtered on the taste of the BDFL and the devteam.
(This is, in fact, why Benevolent Dictator For Life is such a common governance model in our otherwise rather anarchic community. Experience has shown that curation by one person with a clear design vision generally beats attempts to design by committee.)
The same question comes up at other levels. At the whole-program level, we have operating-system distributions precisely in order to curate the riotous diversity of software into semi-coherent wholes with an implied minimum quality threshold. Again: selective pressure.
Rust seems to be missing any analogous mechanism, and that worries me a lot. It’s what I meant when I said in my last post that the swarm attack seems to be failing.
To sharpen this point, I’ll tell you what I think “success” looks like. As a potential Rust user, what I want to do is be able to go from a given feature requirement to one high-quality implementation with an implicit long-term stability guarantee. This, folks, is what a high-quality production language looks like, and not by accident – it minimizes discovery costs for actual production users.
Getting to this from the crate ecology as it is now conceived is not just a technology problem, it’s a a challenge to how the Rust community imagines itself. And, as I trust I’ve made clear, not a unique one. Any sort of open-source ecology eventually has to face a similar transition to maturity.
It could be as conceptually simple as adding a rating system to crates.io, allowing the user to filter on ratings, and having one of the ratings being “Approved by the core team; we take responsibility for this.” But someone is going to have to decide. Who is it going to be? And who decides who will decide?
Backing up a bit: in scheduling theory and operations research there’s a class of problems called “explore/exploit dilemmas”. They show up everywhere where you have limited resources to invest and have to choose between generating options so you’ll have good ones later and harvesting the rewards from those you already have. They show up in the strategy games I like to play, especially in pick-up-and carry games where (say) you’re running a simulated railroad to try to make the money the fastest. Early in the game, you’re mainly interested in investing so you can build an efficient network. But later on you have to back off building track and pile up money using what you have, otherwise you’ll be overtaken by players who chose that transition point more shrewdly.
Rust has built a good machine for exploring. But you guys have competition out there: Go, Nim, Swift, D, and maybe other languages that aren’t on anyone’s radar yet. I think you’re going to need to make that turnover into exploit mode before you know it, and that this is tied into your challenges about curation and governance.
Here’s my advice, if you’ll take it: get conscious!. Grapple with what success looks like from a potential user’s point of view, the challenge of curation, and the problem of who decides. It’s either that, or remain a toy language with an inward-facing community forever.
I wanted to like Rust. I really did. I’ve been investigating it for months, from the outside, as a C replacement with stronger correctness guarantees that we could use for NTPsec.
I finally cleared my queue enough that I could spend a week learning Rust. I was evaluating it in contrast with Go, which I learned in order to evaluate as a C replacement a couple of weeks back.
My chosen learning project in Rust was to write a simple IRC server. As a service daemon with no real-time requirements written around a state machine of the kind I can code practically in my sleep, I thought this would make a good warmup for NTP.
In practice, I found Rust painful to the point of unusability. The learning curve was far worse than I expected; it took me those four days of struggling with inadequate documentation to write 67 lines of wrapper code for the server.
Even things that should be dirt-simple, like string concatenation, are unreasonably difficult. The language demands a huge amount of fussy, obscure ritual before you can get anything done.
The contrast with Go is extreme. By four days in of exploring Go I had mastered most of the language, had a working program and tests, and was adding features to taste.
Then I found out that a feature absolutely critical for writing network servers is plain missing from Rust. Contemplate this bug report: Is there some API like “select/poll/epoll_wait”? and get a load of this answer:
We do not currently have an epoll/select abstraction. The current answer is “spawn a task per socket”.
Upon further investigation I found that there are no proposals to actually fix this problem in the core language. The comments acknowledge that there are a welter of half-solutions in third-party crates but describe no consensus about which to adopt.
Not only that, but it seems the CSP implementation in Rust – the most tractable concurrency primitive – has limits that make it unusable for NTPsec’s purposes (only selection over a static set of channels is possible) and there is some danger that it might be removed entirely!
I have discovered that Rust is not, or not yet, a language suitable for long-term infrastructure work. It suffers from a damning combination of high barriers to entry and technical deficiency.
What is worse is that Rust’s community seems to be unable to fix or even clearly grasp these problems.
I think one problem here is the absence of a strong BDFL providing tasteful design direction and setting priorities. The Rust community appears to have elected to use the decentralized nature of their crate system (which undeniably has some very nice technical properties) to execute a swarm attack on the design space around the language. Which is wonderful in theory but seems to be failing in practice.
UPDATE: This post attracted two kinds of pro-Rust response. One was stupid flamage from zealots. The other was thoughtful commentary from a few people close to the core of the Rust community. The latter group has convinced me that there is considerable awareness of the problems I ran into; a couple even agreed, after analysis, that Rust is at present a poor fit for NTPsec’s requirements. This gives me hope that the Rust of five years from now may become the mature and effective replacement for C that it is not yet.
Of late, it goes like this:
- Upload the code.
- Unplug the FTDI from the Arduino Ethernet and change something.
- Plug it back in.
- FFS, where did /dev/cu.usbserial-WTFBBQ go?
- Yup. It's gone.
- Power cycle my USB hub.
- Oh great, now my Mac's entire USB stack has gone away and now I don't even have a mouse or keyboard.
- Hold down the power button and reboot.
Unplugging the FTDI doesn't always make /dev/cu go away, just like nine times out of ten. But as soon as that happens, I'm within minutes of needing to hold down the power button.
To whom do I address my hate? The authors of the comically horrible Arduino IDE app? I'm gonna guess, "yes, there" because the fucking thing is written in Java and anyone who made that decision any later than 1997 clearly can't be trusted to find their own ass in the dark with both hands. But I would certainly entertain the idea that this is all Apple's fault somehow. Maybe they've assigned maintenance of their USB stack to some intern who sees it as a great learning experience.
But, holy crap, do people really put up with this? Or am I just lucky? Or doing something wrong?
Is someone going to say, "You just unplugged it? You can't just unplug it, USB isn't hot-swappable! Chickens must be bled first!" Ok, but I didn't read anything in the manual about these chickens, tell me more.
Planet Debian upstream is hosted by Branchable.