[Toybox] [PATCH] losetup: Wait for ueventd to create loop device on Android

[Rob Landley]

On 9/16/22 12:03, enh wrote:
>     > which is a shame because, yeah, it does solve
>     > _some_ problems. they're just not problems that _real_ android usage has,
>     at the
>     > cost of introducing ones that do matter to real users. (sorry, yochiang! the
>     > fact that you even know what mount(1) means "you are not the user" :-) )
>     Any ecosystem has layers. Or does McDonalds serving 70 million customers per day
>     and the USA only having 0.7 cattle farms (yes, real numbers) mean McDonalds'
>     "real" concern is the people sitting in its restaurants and nothing else
>     matters?
> 
> (sorry, hadn't noticed this until i saw the rant on your blog :-) )

Which was a bit harsh on my part, sorry. And part of the reason I yanked it is
what I wrote wasn't clearly communicating what I wanted to say.

> to be clear: _my_ job is largely to support users like yochiang. that's
> literally why i moved Android to toybox in the first place --- so that OS
> developers like him (and, to a lesser extent since these tools are less relevant
> to them/less useful in their restricted security context, app developers) have
> everything they'd have if they were developing on linux or macOS.
> 
> but "you are not the user" is a catchphrase we use that's meant to remind us
> that we work on consumer products, and should always be asking ourselves whether
> we're actually helping consumers.

Android developers are probably currently outnumbered by users something like
10,000 to 1 even counting third party developers, yes.

I think more users should have the ability to develop, at least a tiny bit. Not
an _obligation_ to do so, but a nonthreatening opportunity they're free to
ignore, with a low enough barrier to entry they can dabble in without
committing. With a user pool that big, 0.1% uptake is a lot.

> to take your restaurant analogy, i think it's quite clear that, yes, a
> restaurant should optimize for the people sitting in the restaurant. that is
> literally their business. (and we have multiple restaurant options available
> because even "people sitting in the restaurant" isn't one homogenous group, and
> even the same person at different times might make different restaurant choices.
> consumers who care more about farmers or animals aren't eating at your fast food
> restaurant anyway.)

If one group is consuming the output of the other, the producers are part of the
process. Without producers, there are no consumers.

> the code in init's job is to ensure various security properties which devtmpfs
> as it stands is not capable of doing. so the question is "does devtmpfs have
> advantages that would warrant the work of effectively redesigning and
> reimplementing it in the upstream kernel, and then switching the whole ecosystem
> over to using it?". and so far "it'd let us remove an ugly two-line hack from
> toybox" is the only advantage i'm aware of, so ... the cost/benefit analysis
> really isn't working out there :-)

You're aware of other people interested enough to look into it, but their
motivating use cases weren't logged. (That's a problem I hit in the embedded
space a lot, right up there with people who poke me privately instead of
addressing to something like linux-kernel publicly.)

Yes for devtmpfs it's totally possible to cope. It wasn't really this specific
issue, I was reacting to "not a real" and "you aren't the" which seemed to be
assigning _zero_ weight to developers concerns. We don't have resources to
assign to this is not the same as you're wrong to care about this.

Part of what I want to do is help Android become a general purpose development
base that can _export_ technology. I want to invert "AOSP is cross compiled from
PCs to phone hardware" so cloud and embedded stuff ("embedded" is not just IOT
but delivery drones and self driving cars) can be created and upgraded from
phones and tablets.

People have experimentally made various laptop form factor
display/battery/keyboard enclosures a phone plugs into, but those haven't taken
off because when you plug a phone into one, there's still a lot you can do with
laptop software that you can't with a phone. Phones haven't really tried to eat
the PC space the way the PC ate the minicomputer and mainframe spaces before it.
(A lot of "tablet with a keyboard cover" floated up into the netbook space
shortly before the pandemic killed Austin's Fry's, but the system installed on
those wasn't android.)

One of the defining features of "big iron" is nobody learns to do it except for
work. Newbie developers target the machine in front of them, and these days
that's phones. The PC is becoming big iron, like the mainframe and minicomputer
before it, but the first PCs had BASIC in ROM and phones don't even have LOGO.
These days on average kids get their first phone at 10 years old (according to
https://www.inc.com/melanie-curtin/bill-gates-says-this-is-the-safest-age-to-give-a-child-a-smartphone.html)
and out of the box they can author youtube videos with it, but not software.

At the other end conventional Linux development has the problem that "the
average age of Linux developers is Linus' age" which is gonna bite pretty hard
in another 10-15 years. The Linux Foundation has successfully purged most
hobbyists from Linux development (in the US, Europe still seems to have some)
and the ecosystem is getting WAY more complicated which means the barrier to
entry for a basic understanding of what's going on without significant black
magic and black boxes goes way up. (Last week chrome could talk to my website
but command line utilities like ssh said no route to host, and I'm going
"Running as different users... No. DNS cacheing... no. ipv6 routing vs ipv4?
No... I was doing container stuff in another window, make sure that's cleaned
up... no. Restart the wicd network manager... why did that fix it? Not a clue,
but can no longer reproduce the issue so can't debug further, hope it doesn't
happen again." Add systemd and selinux to that and I wouldn't know where to start.)

I want to bring the ability to develop software to where people are. In the
short term an app with the cartoony appeal of logo or quickbasic or visual basic
or whatever java beans was trying to accomplish would probably be a better
immediate solution. But I'm trying to solve the larger problem of making people
with phones not be second class citizens to people with PCs: if there's
something you can ONLY do on a PC and cannot accomplish on a phone, then the
minority with PCs are still superior to the majority with phones. And if I
expect PC volume to inevitably decline and phones to remain literally more
common than indoor plumbing, that's not a good thing. Which is why I want
Android users-turned-developers to be able to naturally expand their programming
chops all the way to the bare metal.

It is in that context that "you're a developer, you don't matter" hits me funny.
Within the team Android is paying, as of today, sure. In the larger ecosystem,
and in future, I really hope not.

> the way to change that would be either reduce the cost (because upstream ends up
> with something we can use, but that seems unlikely without us doing a ton of
> work that no-one else would thank us for anyway) or increase the benefit ...
> which brings us back to "you are not the user". i'm unable to come up with any
> way in which devtmpfs would make consumers' lives better (or even partners'
> lives), and given that opportunity cost is always important, i can think of a
> ton of things those person-years could more usefully be spent on.

I agree it makes perfect sense for Android to bounce devtmpfs for now. (The fact
linux-kernel hasn't made devtmpfs useful to you is a failure of communication
and a failure of linux-kernel, but that's a separate issue from Android staffing
an engineering project.)

> (obviously this would be different if the costs of the status quo were higher.
> but like i say, right now afaik that's basically just this one hack.)

Oh sure. But going forward, it's a todo item for me. "Can't fix now" != "won't fix".

>     Rob

Rob

P.S. Pascal's apology again. I still didn't manage to say the above in a
reasonable amount of space.