May 14, 2019

The Next Part Of The Process

Filed under: digital,documentation,future,interfaces,irc,mozilla,work — mhoye @ 12:05 pm


I’ve announced this upcoming change and the requirements we’ve laid out for a replacement service for IRC, but I haven’t widely discussed the evaluation process in any detail, including what you can expect it to look like, how you can participate, and what you can expect from me. I apologize for that, and really should have done so sooner.

Briefly, I’ll be drafting a template doc based on our stated requirements, and once that’s in good, markdowny shape we’ll be putting it on GitHub with preliminary information for each of the stacks we’re considering and opening it up to community discussion and participation.

From there, we’re going to be taking pull requests and assembling our formal understanding of each of the candidates. As well, we’ll be soliciting more general feedback and community impressions of the candidate stacks on Mozilla’s Community Discourse forum.

I’ll be making an effort to ferry any useful information on Discourse back to GitHub, which unfortunately presents some barriers to some members of our community.

While this won’t be quite the same as a typical RFC/RFP process – I expect the various vendors as well as members the Mozilla community to be involved – we’ll be taking a lot of cues from the Rust community’s hard-won knowledge about how to effectively run a public consultation process.

In particular, it’s critical to me that this process to be as open and transparent as possible, explicitly time-boxed, and respectful of the Mozilla Community Participation Guidelines (CPG). As I’ve mentioned before, accessibility and developer productivity will both weigh heavily on our evaluation process, and the Rust community’s “no new rationale” guidelines will be respected when it comes time to make the final decision.

When it kicks off, this step will be widely announced both inside and outside Mozilla.

As part of that process, our IT team will be standing up instances of each of the candidate stacks and putting them behind the Participation Systems team’s “Mozilla-IAM” auth system. We’ll be making them available to the Mozilla community at first, and expanding that to include Github and via-email login soon afterwards for broader community testing. Canonical links to these trial systems will be prominently displayed on the GitHub repository; as the line goes, accept no substitutes.

Some things to note: we will also be using this period to evaluate these tools from a community moderation and administration perspective as well, to make sure that we have the tools and process available to meaningfully uphold the CPG.

To put this somewhat more charitably than it might deserve, we expect that some degree of this testing will be a typical if unfortunate byproduct of the participative process. But we also have plans to automate some of that stress-testing, to test both platform API usability and the effectiveness of our moderation tools. Which I suppose is long-winded way of saying: you’ll probably see some robots in there play-acting at being jerks, and we’re going to ask you to play along and figure out how to flag them as bad actors so we can mitigate the jerks of the future.

As well, we’re going to be doing the usual whats-necessaries to avoid the temporary-permanence trap, and at the end of the evaluation period all the instances of our various candidates will be shut down and deleted.

Our schedule is still being sorted out, and I’ll have more about that and our list of candidates shortly.

May 3, 2019

Goals And Constraints

Filed under: digital,documentation,flickr,future,interfaces,linux,mozilla,work — mhoye @ 12:30 pm

This way to art.

I keep coming back to this:

“Open” in this context inextricably ties source control to individual agency. The checks and balances of openness in this context are about standards, data formats, and the ability to export or migrate your data away from sites or services that threaten to go bad or go dark. This view has very little to say about – and is often hostile to the idea of – granular access restrictions and the ability to impose them, those being the tools of this worldview’s bad actors.

The blind spots of this worldview are the products of a time where someone on the inside could comfortably pretend that all the other systems that had granted them the freedom to modify this software simply didn’t exist. Those access controls were handled, invisibly, elsewhere; university admission, corporate hiring practices or geography being just a few examples of the many, many barriers between the network and the average person.

And when we’re talking about blind spots and invisible social access controls, of course, what we’re really talking about is privilege.

How many people get to have this, I wonder: the sense that they can sit down in front of a computer and be empowered by it. The feeling of being able, the certainty that you are able to look at a hard problem, think about it, test and iterate; that easy rapid prototyping with familiar tools is right there in your hands, that a toolbox the size of the world is within reach. That this isn’t some child’s wind up toy I turn a crank on until the powerpoint clown pops up.

It’s not a universal or uniform experience, to be sure; they’re machines made of other people’s choices, and computers are gonna computer. But the only reason I get to have that feeling at all is that I got my start when the unix command line was the only decent option around, and I got to put the better part of a decade grooving in that muscle memory on machines and forums where it was safe – for me at least – to be there, fully present, make mistakes and learn from them.

(Big shoutout to everyone out there who found out how bash wildcards work by inadvertently typing mv * in a directory with only two files in it.)

That world doesn’t exist anymore; the internet that birthed it isn’t coming back. But I want everyone to have this feeling, that the machine is more than a glossy appliance. That it’s not a constraint. That with patience and tenacity it can work with you and for you, not just a tool for a task but an extension and expression of ourselves and our intent. That a computer can be a tool for expressing ourselves, for helping us be ourselves better.

Last week I laid out the broad strokes of Mozilla’s requirements for our next synchronous-text platform. They were pretty straightforward, but I want to thank a number of people from different projects who’ve gotten in touch on IRC or email to ask questions and offer their feedback.

Right now I’d like to lay out those requirements in more detail, and talk about some of the reasons behind them. Later I’m going to lay out the process and the options we’re looking at, and how we’re going to gather information, test those options and evaluate what we learn.

While the Rust community is making their own choices now about the best fit for their needs, the Rust community’s processes are going to strongly inform the steps for Mozilla. They’ve learned a lot the hard way about consensus-building and community decision-making, and it’s work that I have both a great deal of respect for and no intention of re-learning the hard way myself. I’ll have more about that shortly as well.

I mentioned our list of requirements last week but I want to drill into some of them here; in particular:

  • It needs to be accessible to the greater Mozilla community.

This one implies a lot more than it states, and it would be pretty easy to lay out something trite like “we think holistically about accessibility” the way some organizations say “a diversity of ideas”, as though that means anything at all. But that’s just not good enough.

Diversity, accessibility and community are all tightly interwoven ideas we prize, and how we approach, evaluate and deploy the technologies that connect us speaks deeply to our intentions and values as an organization. Mozilla values all the participants in the project, whether they rely on a screen reader, a slow network or older hardware; we won’t – we can’t – pick a stack that treats anyone like second-class citizens. That will not be allowed.

  • While we’re investigating options for semi-anonymous or pseudonymous connections, we will require authentication, because:
  • The Mozilla Community Participation Guidelines will apply, and they’ll be enforced.

Last week Dave Humphrey wrote up a reminiscence about his time on IRC soon after I made the announcement. Read the whole thing, for sure. Dave is wiser and kinder than I am, and has been for as long as we’ve known each other; his post spoke deeply to many of us who’ve been in and around Mozilla for a while, and two sentences near the end are particularly important:

“Having a way to get deeply engaged with a community is important, especially one as large as Mozilla. Whatever product or tool gets chosen, it needs to allow people to join without being invited.”

We’ve got a more detailed list of functional and organizational requirements for this project, and this is an important part of it: “New users must be able to join the service without manual intervention from a Mozilla employee.”

We’ve understood this as an accessibility issue for a long time as well, though I don’t think we’ve ever given it a name. “Involvement friction”, maybe – everything about becoming part of a project and community that’s hard not because it’s inherently difficult, but because nobody’s taken the time to make it easy.

I spend a lot of time thinking about something Sid Wolinsky said about the first elevators installed in the New York subway system: “This elevator is a gift from the disability community and the ADA to the nondisabled people of New York”. If you watch who’s using the elevators, ramps or automatic doors in any public building long enough, anything with wheelchair logo on it, you’ll notice a trend: it’s never somebody in a wheelchair. It’s somebody pushing a stroller or nursing a limp. It’s somebody carrying an awkward parcel, or a bag of groceries. Sometimes it’s somebody with a coffee in one hand and a phone in the other. Sometimes it’s somebody with no reason at all, at least not one you can see. It’s people who want whatever thing they’re doing, however difficult, to be a little bit easier. It’s everybody.

If you cost out accessible technology for the people who rely on it, it looks really expensive; if you cost it out for everyone who benefits from it, though, it’s basically free. And none of us in the “benefit” camp are ever further than a sprained ankle away from “rely”.

We’re getting better at this at Mozilla in hundreds of different ways, at recognizing how important it is that the experience of getting from “I want to help” to “I’m set up to help” to “I’m helping” be as simple and painless as possible. As one example, our bootstrap scripts and mach-build have reduced our once-brittle, failure-prone developer setup process down to “answer these questions and wait for the downloads to finish”, and in the process have done more to make the Firefox codebase accessible than I ever will. And everyone relies on them now, first-touch contributors and veteran devs alike.

Getting involved in the community, though, is still harder than it needs to be; try watching somebody new to open source development try to join an IRC channel sometime. Watch them go from “what’s IRC” to finding a client to learning how to use the client to joining the right server, then the right channel, only to find that the reward for all that effort is no backscroll, no context, and no idea who you’re talking to or if you’re in the right place or if you’re shouting into the void because the people you’re looking for aren’t logged in at the same time. It’s like asking somebody to learn to operate an airlock on their own so they can toss themselves out of it.

It’s more than obvious that you don’t build products like that anymore, but I think it’s underappreciated that it’s just as true of communities. I think it’s critical that we bring that same discipline of caring about the details of the experience to our communications channels and community forums, and the CPG is the cornerstone of that effort.

It was easy not to care about this when somebody who wanted to contribute to an open source project with global impact had maybe four choices, the Linux kernel, the Mozilla suite, the GNU tools and maybe Apache. But that world was pre-Github, pre-NPM. If you want to work on hard problems with global impact now you have a hundred thousand options, and that means the experience of joining and becoming a part of the Mozilla community matters.

In short, the amount of effort a project puts into making the path from “I want to help” to “I’m helping” easier is a reliable indicator of the value that project puts on community involvement. So if we say we value our community, we need to treat community involvement and contribution like a product, with all the usability and accessibility concerns that implies. To drive involvement friction as close to zero as possible.

One tool we’ll be relying on – and this one, we did build in-house – is called Mozilla-IAM, Mozilla’s Identity and Access Management tool. I’ll have more to say about this soon, but at its core it lets us proxy authentication from various sources and methods we trust, Github, Firefox Accounts, a link in your email, a few others. We think IAM will let us support pseudonymous participation and a low-cost first-contact experience, but also let us keep our house in order and uphold the CPG in the process.

Anyway, here’s a few more bullet points; what requirements doc isn’t full of them?

A synchronous messaging system that meets our needs:

  • Must work correctly in unmodified, release-channel Firefox.
  • Must offer a solid mobile experience.
  • Must support thousands of simultaneous users across the service.
  • Must support easy sharing of hyperlinks and graphics as well as text.
  • Must have persistent scrollback. Users reconnecting to a channel or joining the channel for the first time must be able to read up to acquire context of the current conversation in the backscroll.
  • Programmatic access is a hard requirement. The service must support a mature, reasonably stable and feature-rich API.
  • As mentioned, people participating via accessible technologies including screen readers or high-contrast display modes must be able to participate as first-class citizens of the service and the project.
  • New users must be able to join the service without manual intervention from a Mozilla employee.
  • Whether or not we are self-hosting, the service must allow Mozilla to specify a data retention and security policy that meets our institutional standards.
  • The service must have a customizable first-contact experience to inform new participants about Mozilla’s CPG and privacy notice.
  • The service must have effective administrative tooling including user and channel management, alerting and banning.
  • The service must support delegated authentication.
  • The service must pass an evaluation by our legal, trust and security teams. This is obviously also non-negotiable.

I doubt any of that will surprise anyone, but they might, and I’m keeping an eye out for questions. We’re still talking this out in #synchronicity on irc.m.o, and you’re welcome to jump in.

I suppose I should tip my hand at this point, and say that as much as I value the source part of open source, I also believe that people participating in open source communities deserve to be free not only to change the code and build the future, but to be free from the brand of arbitrary, mechanized harassment that thrives on unaccountable infrastructure, federated or not. We’d be deluding ourselves if we called systems that are just too dangerous for some people to participate in at all “open” just because you can clone the source and stand up your own copy. And I am absolutely certain that if this free software revolution of ours ends up in a place where asking somebody to participate in open development is indistinguishable from asking them to walk home at night alone, then we’re done. People cannot be equal participants in environments where they are subject to wildly unequal risk. People cannot be equal participants in environments where they are unequally threatened.

I think we can get there; I think we can meet our obligations to the Mission and the Manifesto as well as the needs of our community, and help the community grow and thrive in a way that grows and strengthens the web want and empowers everyone using and building it to be who we’re aspiring to be, better.

The next steps are going to be to lay out the evaluation process in more detail; then we can start pulling in information, stand up instances of the candidate stacks we’re looking at and trying them out.

April 26, 2019

Synchronous Text

Filed under: digital,documentation,future,interfaces,irc,mozilla,work — mhoye @ 12:44 pm


Let’s lead with the punchline: the question of what comes after IRC, for Mozilla, is now on my desk.

I wasn’t in the room when was stood up, but from what I’ve heard IRC wasn’t “chosen” so much as it was the obvious default, the only tool available in the late ’90s. Suffice to say that as a globally distributed organization, Mozilla has relied on IRC as our main synchronous communications tool since the beginning. For much of that time it’s served us well, if for some less-than-ideal values of “us” and “well”.

Like a lot of the early internet IRC is a quasi-standard protocol built with far more of the optimism of the time than the paranoia the infosec community now refers to as “common sense”, born before we learned how much easier it is to automate bad acts than it is to foster healthy communities. Like all unauthenticated systems on the modern net it’s aging badly and showing no signs of getting better.

While we still use it heavily, IRC is an ongoing source of abuse and harassment for many of our colleagues and getting connected to this now-obscure forum is an unnecessary technical barrier for anyone finding their way to Mozilla via the web. Available interfaces really haven’t kept up with modern expectations, spambots and harassment are endemic to the platform, and in light of that it’s no coincidence that people trying to get in touch with us from inside schools, colleges or corporate networks are finding that often as not IRC traffic isn’t allowed past institutional firewalls at all.

All of that adds up to a set of real hazards and unnecessary barriers to participation in the Mozilla project; we definitely still need a globally-available, synchronous and text-first communication tool; our commitment to working in the open as an organization hasn’t changed. But we’re setting a higher bar for ourselves and our communities now and IRC can’t meet that bar. We’ve come to the conclusion that for all IRC’s utility, it’s irresponsible of us to ask our people – employees, volunteers, partners or anyone else – to work in an environment that we can’t make sure is healthy, safe and productive.

In short, it’s no longer practical or responsible for us to keep that forum alive.

In the next small number of months, Mozilla intends to deprecate IRC as our primary synchronous-text communications platform, stand up a replacement and decommission soon afterwards. I’m charged with leading that process on behalf of the organization.

Very soon, I’ll be setting up the evaluation process for a couple of candidate replacement stacks. We’re lucky; we’re spoiled for good options these days. I’ll talk a bit more about them in a future post, but the broad strokes of our requirements are pretty straightforward:

  • We are not rolling our own. Whether we host it ourselves or pay for a service, we’re getting something off the shelf that best meets our needs.
  • It needs to be accessible to the greater Mozilla community.
  • We are evaluating products, not protocols.
  • We aren’t picking an outlier; whatever stack we choose needs to be a modern, proven service that seems to have a solid provenance and a good life ahead of it. We’re not moving from one idiosyncratic outlier stack to another idiosyncratic outlier stack.
  • While we’re investigating options for semi-anonymous or pseudonymous connections, we will require authentication, because:
  • The Mozilla Community Participation Guidelines will apply, and they’ll be enforced.

I found this at the top of a draft FAQ I’d started putting together a while back. It might not be what you’d call “complete”, but maybe it is:

Q: Why are we moving away from IRC? IRC is fine!
A: IRC is not fine.

Q: Seriously? You’re kidding, right?
A: I’m dead serious.

I don’t do blog comments anymore – unfortunately, for a lot of the same reasons I’m dealing with this – but if you’ve got questions, you can email me.

Or, if you like, you can find me on IRC.

April 17, 2019

Why Don’t You Just

Filed under: documentation,interfaces,life,vendetta — mhoye @ 12:12 pm

This is a rough transcript of short talk I gave at a meeting I was in a few years ago. Enough time has passed that I don’t feel like I’m airing out any dirty laundry, and nothing’s brought this on but the periodic requests I get to publish it. No, I won’t be taking questions. I hope it’s useful to someone.

Can I get a show of hands here? Raise your hands if your job is hard. Raise your hand if there are a lot of difficult trade-offs, weird constraints and complicated edge-cases in it, that aren’t intuitively obvious until you’ve spent a lot of time deep in the guts of the problems you’re working on.

[everyone raises hands]

OK, now keep your hand up if you’re only here for the paycheck and the stickers.

[everyone lowers hands]

I’d like to try to convince you that there’s a negative space around every conversation we have that’s made up of all the assumptions we’ve made, of all the opinions we hold that led us to make whatever claim we’re making. Of all the things that we don’t say out loud that are just as much a part of that conversation as the things we do.

Whenever you look at a problem somebody’s been working on for a week or a month or maybe years and propose a simple, obvious solution that just happens to be the first thing that comes into your head, then you’re also making it crystal clear to people what you think of them and their work.

“I assume your job is simple and obvious.”

“Maybe if you’ve been working on a problem this simple for this long, you’re not that smart.”

“Maybe if it’s taken you this long to solve this simple, obvious problem, maybe the team you’re working with is incompetent?”

“Why has your manager, why has your whole management chain had you working on this problem for so long, when the answer is so simple and obvious?”

“And even if I’m wrong about that, your job doesn’t matter enough for me to be the least bit curious about it.”

There’s not a single person in this room who’d ever say something like this to one of their colleagues’ faces, I hope. But somehow we have a lot of conversations here that involve the phrase “why don’t you just”.

One of the great burdens on us as leaders is that humans have feelings and words mean things. Our effectiveness rests on our ability and willingness to collaborate, and the easiest way to convey that you respect somebody’s work is to have enough curiosity and humility to open conversations with the assumption that maybe the other person’s job is just as challenging and complicated and important as yours.

This “why don’t you just” thing is bullshit. Our people deserve better and I want it to stop.

Thank you.

April 10, 2019

Modern Problems, Etc.

Filed under: analog,awesome,future,interfaces,life,lunacy,weird — mhoye @ 10:51 am


April 9, 2019


Filed under: a/b,arcade,digital,documentation,interfaces,vendetta — mhoye @ 8:57 am

Tevis Thompson, games critic and author of the excellent Second Quest has posted a new article on the best and worst games of 2018, and as always his work is worth your time.

So the question is not: what is it? Or: is it good? The question is: why are you still playing? Why do you need another chaos box? Was the tropical island version not enough in 2012? Nor the Himalayan one in 2014? Did you really need the rural American flavor too? I know this isn’t your first rodeo. Chaos boxes were kinda novel and fun in the 2000s, but there’s nothing wild or crazy about them now, no matter how many grizzly bears named Cheeseburger you stuff in. Surely you have a higher standard for dipshittery in 2018. Besides, there are so many virtual ways to unwind and let off steam these days. So why are you still playing this?

I’ll tell you why: because you like high definition murder. You like it. It’s not an accident that the most violent shooters are always on the cutting edge of graphical fidelity. They know what you want. And as your stunted adult imagination knows, mouth gun sounds just won’t cut it anymore. You need 4K fire and blood, bodies twisting and breaking at 60 frames per second. You need local color to give just enough specificity and grit to make each shot really land, to make sure your deadened senses feel anything at all. You especially need a charismatic villain to see you, recognize your violence, say you’re just like him. And then, absolve you. Because both of you poor souls have no other way to be in this fallen world. Except that he’s a videogame character and you’re a person.

That’s part of his review of Far Cry 5, a game that only took second place on his list of the worst games of the year. He digs into the first, Red Dead Redemption 2, at much greater length.

Read the whole thing.

April 2, 2019

Occasionally Useful

A bit of self-promotion: the UsesThis site asked me their four questions a little while ago; it went up today.

A colleague once described me as “occasionally useful, in the same way that an occasional table is a table.” Which I thought was oddly nice of them.

March 27, 2019

Defined By Prosodic And Morphological Properties

Filed under: academia,academic,awesome,interfaces,lunacy,science — mhoye @ 5:09 pm


I am fully invested in these critical advances in memetic linguistics research:

[…] In this paper, we go beyond the aforementioned prosodic restrictions on novel morphology, and discuss gradient segmental preferences. We use morphological compounding to probe English speakers’ intuitions about the phonological goodness of long-distance vowel and consonant identity, or complete harmony. While compounding is a central mechanism for word-building in English, its phonology does not impose categorical vowel or consonant agreement patterns, even though such patterns are attested cross-linguistically. The compound type under investigation is a class of insult we refer to as shitgibbons, taking their name from the most prominent such insult which recently appeared in popular online media (§2). We report the results of three online surveys in which speakers rated novel shitgibbons, which did or did not instantiate long-distance harmonies (§3). With the ratings data established, we follow two lines of inquiry to consider their source: first, we compare shitgibbon harmony preferences with the frequency of segmental harmony in English compounds more generally, and conclude that the lexicon displays both vowel and consonant harmony (§4); second, we attribute the lack of productive consonant harmony in shitgibbons to the attested cross-linguistic harmonies, which we implement as a locality bias in MaxEnt grammar (§5).

You had me at “diddly-infixation”.

January 20, 2019

Super Mario Telemachy

Filed under: a/b,arcade,awesome,beauty,digital,documentation,future,interfaces — mhoye @ 10:29 pm
This way to art.

One thing I love about the Hyrule of Breath of the Wild is how totally unbothered it is by our hero’s presence in it. Cliffs you can’t climb, monsters you have no real shot at beating, characters wandering about who aren’t there as side-quest farmers or undifferentiated foils for your inevitable progress. Even the weather will inconvenience, injure or outright murder you if you walk out into it dressed wrong, and in large ways and small this mattered. I’d seen lighting strikes in the game before – and getting one-shotted by the rain after I missed the memo about not wearing metal out in a storm was startling enough, lemme tell you – but the first time I saw one hit water, saw a handful of stunned fish floating to the surface, that put my jaw on the floor. The rain that made this hill too slippery to climb gave that world the sense of a being a world, one that for all your power and fate and destiny just didn’t revolve around you.

Super Mario Odyssey is the precise, exact opposite of that, and at first I really didn’t get it. I couldn’t get into it.

It’s surprisingly hard to enjoy an entire world carefully and forgivingly tuned to precisely fit your exact capacities at all times, to the point that if you’ve done much platforming in your life there’s no real challenge to navigating Odyssey, much less risk. A “death” that costs you about six of the abundant, constantly replenished gold coins that litter the landscape hardly even counts as a setback – you’re likely to restart next to eight or ten of them! – so my first impressions were that it amounted to a hoarder’s brightly coloured to-do list. I decided to grind through it to see the New Donk City I’d been studiously avoiding spoilers for, hearing only that it was the best and weirdest part of the game, but it was definitely a grind.

But after watching my kids play it, and helping them through the parts they’ve been hung up on, I realized something: Odyssey is a bad single-player game because it’s not a single-player game, at least not a single adult player. It’s a children’s book, a children’s experience; it’s Mario Disneyland. And once I discovered the game I was actually supposed to be playing, the whole experience changed.

With fresh eyes and unskilled hands involved, this sprawling, tedious fan-service buffet becomes an entirely different thing, a chance to show my kids around a game world I grew up with. Even the 2D sidescroller diversions, eye-rollingly retro on their own, become a conversation. Most amazingly, to me at least, the two-player option – one player driving Mario, the other driving his ghost hat companion Cappy – stops looking like a silly gimmick and starts looking like a surprisingly good execution of a difficult idea I’ve wanted for a long time. Odyssey is the only game I’ve ever seen that has cooperative, same-couch multiplayer that’s accessible to people of wildly different skill levels. Another way to say that is, it’s a game I can play with my kids; not versus, not taking turns, but “with” for real, and it’s kind of great.

So, playing Odyssey alone by myself? Sure: unchallenging, rote and if we’re honest enough to admit it, a little sad. But with my kids’ playing it, playing along together? Definitely. Not only good but good fun, maybe even a meaningful experience. Sign me up.

January 8, 2019

Feature Request

Filed under: digital,documentation,fail,interfaces,linux,toys,vendetta,want — mhoye @ 9:50 am

If I’m already in a Linux, ideally a Debian-esque Linux, is there a way for me to say “turn this new external hard drive into a bootable Linux that’s functionally identical to this current machine”? One that doesn’t involve any of dd, downloading an ISO or rebooting? It’s hard to believe this is as difficult as it seems, or that this isn’t a standard tool yet, but if it is I sure can’t find it.

Every installer I’ve seen since the first time I tried the once-magical Knoppix has let you boot into a workable Linux on its own and install that Linux to the hard drive if you like, but I can’t a standalone tool that does the same from a running system.

What I’m after is a tool (I briefly wrote “ideally graphical”, but yeah. Let’s be real here.) that you point at a hard drive, that:

  • Formats this new hard drive in some rough approximation of what you’ve already got and making it bootable. (grub-whatever?)
  • Installs the same packages onto that drive as are on the host system, and
  • Optionally copies over account information required, /home/*, passwords, whatever else is in /etc or /opt; skip (or be smart about?) stuff like the hostname or iptables, maybe.

…and ends with a hard drive I can plug into another system, boot and log into as comfortably-preconfigured me.

debootstrap almost gets part of the way there, and you can sort of convince that or multistrap to do the job if you scrape out your current config, pour it into a config file and rsync over a bunch of other stuff. But then I’m back in roll-it-yourself-land where I started.

Ideally this apparently-hypothetical magic clone tool would be able to do this with minimal network traffic, too – it’s likely I’ve already got many or most of those packages cached, no? And alternatively, it’d also be nice to able to keep my setup largely intact while migrating across architectures.

I go looking for this every few years, even though it puts me briefly back on the “why would you ever do it like that? You should switch distros!” You Asked A Linux Question On The Internet Treadmill. But I haven’t found a decent answer yet beyond rolling my own.


(Comments are off permanently. You’re welcome to mail me, though?)

Older Posts »

Powered by WordPress