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

[enh]

On Sat, Sep 17, 2022 at 8:15 AM Rob Landley <rob at landley.net> wrote:

> 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.)
>

oh, specifically for this, i've never heard anyone have a motivation other
than "can't we get rid of this and just use the upstream thing?". each time
they've realized it's not trivial, they've remembered that they have better
things to do with their time. (which is what this kind of question usually
really boils down to --- opportunity cost.)


> 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.
>

i should probably try to come up with better wording since it's
demonstrably causing confusion, but basically it ends up sounding like that
for two reasons:

1. opportunity cost. with a fixed number of people and a fixed amount of
time, you have to decide where you'll get the most return on your time
investment --- if you're doing A, you can't also be doing B, so A better be
worth it.

2. realism. there's a big philosophical difference between people who like
to keep open bugs that they know they're never going to have time to work
on (because, yes, the bug is valid) and those who prefer to close them
(because, no, we'll never have time to work on this). both choices suck,
and upset someone, so it's really just down to personality which you end up
going with.  since we have processes to make sure we keep looking at bugs,
and people tend to be stressed by ever-increasing piles of bugs, i've moved
from "of course it should stay open --- it's clearly a legit bug!" to "this
will never make the cut and get fixed [without a new bug that has much more
convincing cost/benefit], so let's not annoy ourselves and others".


> 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.
>

like i said, the bit you're missing here is that i was only talking about
this bug. otherwise we'd never have switched to toybox in the first place,
and we wouldn't still be having discussions about it --- we'd have just
called 0.7 or whatever it was "good enough" and moved on.

really it's just "there's no world i can imagine right now where moving to
devtmpfs is worth the time and effort". it hardly buys us anything, and it
would be very expensive to do. if you're going to do something very
expensive, you need to be able to claim that "3 billion users" multiplier,
and "we'd be able to remove a hack from losetup" isn't even close :-)

(and even if we suddenly found ourselves with more people, stuff like the
kernel's handling of hardware randomness sources would be way more valuable
to way more people, for example. it's opportunity costs all the way down...)


> > 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".
>

yes, it's quite clear you're in the other philosophical camp :-)

neither is wrong, but they're unfortunately quite incompatible in
conversation.


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

well, if i hadn't tried to save myself 30s by saying "you are not the user"
(which is pretty well known to most googlers [but even there, not
everyone]), we could have avoided this whole thread...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220920/61dc25ff/attachment-0001.htm>