<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 17, 2022 at 8:15 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 9/16/22 12:03, enh wrote:<br>
> > which is a shame because, yeah, it does solve<br>
> > _some_ problems. they're just not problems that _real_ android usage has,<br>
> at the<br>
> > cost of introducing ones that do matter to real users. (sorry, yochiang! the<br>
> > fact that you even know what mount(1) means "you are not the user" :-) )<br>
> Any ecosystem has layers. Or does McDonalds serving 70 million customers per day<br>
> and the USA only having 0.7 cattle farms (yes, real numbers) mean McDonalds'<br>
> "real" concern is the people sitting in its restaurants and nothing else<br>
> matters?<br>
> <br>
> (sorry, hadn't noticed this until i saw the rant on your blog :-) )<br>
<br>
Which was a bit harsh on my part, sorry. And part of the reason I yanked it is<br>
what I wrote wasn't clearly communicating what I wanted to say.<br>
<br>
> to be clear: _my_ job is largely to support users like yochiang. that's<br>
> literally why i moved Android to toybox in the first place --- so that OS<br>
> developers like him (and, to a lesser extent since these tools are less relevant<br>
> to them/less useful in their restricted security context, app developers) have<br>
> everything they'd have if they were developing on linux or macOS.<br>
> <br>
> but "you are not the user" is a catchphrase we use that's meant to remind us<br>
> that we work on consumer products, and should always be asking ourselves whether<br>
> we're actually helping consumers.<br>
<br>
Android developers are probably currently outnumbered by users something like<br>
10,000 to 1 even counting third party developers, yes.<br>
<br>
I think more users should have the ability to develop, at least a tiny bit. Not<br>
an _obligation_ to do so, but a nonthreatening opportunity they're free to<br>
ignore, with a low enough barrier to entry they can dabble in without<br>
committing. With a user pool that big, 0.1% uptake is a lot.<br>
<br>
> to take your restaurant analogy, i think it's quite clear that, yes, a<br>
> restaurant should optimize for the people sitting in the restaurant. that is<br>
> literally their business. (and we have multiple restaurant options available<br>
> because even "people sitting in the restaurant" isn't one homogenous group, and<br>
> even the same person at different times might make different restaurant choices.<br>
> consumers who care more about farmers or animals aren't eating at your fast food<br>
> restaurant anyway.)<br>
<br>
If one group is consuming the output of the other, the producers are part of the<br>
process. Without producers, there are no consumers.<br>
<br>
> the code in init's job is to ensure various security properties which devtmpfs<br>
> as it stands is not capable of doing. so the question is "does devtmpfs have<br>
> advantages that would warrant the work of effectively redesigning and<br>
> reimplementing it in the upstream kernel, and then switching the whole ecosystem<br>
> over to using it?". and so far "it'd let us remove an ugly two-line hack from<br>
> toybox" is the only advantage i'm aware of, so ... the cost/benefit analysis<br>
> really isn't working out there :-)<br>
<br>
You're aware of other people interested enough to look into it, but their<br>
motivating use cases weren't logged. (That's a problem I hit in the embedded<br>
space a lot, right up there with people who poke me privately instead of<br>
addressing to something like linux-kernel publicly.)<br></blockquote><div><br></div><div>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.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Yes for devtmpfs it's totally possible to cope. It wasn't really this specific<br>
issue, I was reacting to "not a real" and "you aren't the" which seemed to be<br>
assigning _zero_ weight to developers concerns. We don't have resources to<br>
assign to this is not the same as you're wrong to care about this.<br></blockquote><div><br></div><div>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:</div><div><br></div><div>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.</div><div><br></div><div>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".</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Part of what I want to do is help Android become a general purpose development<br>
base that can _export_ technology. I want to invert "AOSP is cross compiled from<br>
PCs to phone hardware" so cloud and embedded stuff ("embedded" is not just IOT<br>
but delivery drones and self driving cars) can be created and upgraded from<br>
phones and tablets.<br>
<br>
People have experimentally made various laptop form factor<br>
display/battery/keyboard enclosures a phone plugs into, but those haven't taken<br>
off because when you plug a phone into one, there's still a lot you can do with<br>
laptop software that you can't with a phone. Phones haven't really tried to eat<br>
the PC space the way the PC ate the minicomputer and mainframe spaces before it.<br>
(A lot of "tablet with a keyboard cover" floated up into the netbook space<br>
shortly before the pandemic killed Austin's Fry's, but the system installed on<br>
those wasn't android.)<br>
<br>
One of the defining features of "big iron" is nobody learns to do it except for<br>
work. Newbie developers target the machine in front of them, and these days<br>
that's phones. The PC is becoming big iron, like the mainframe and minicomputer<br>
before it, but the first PCs had BASIC in ROM and phones don't even have LOGO.<br>
These days on average kids get their first phone at 10 years old (according to<br>
<a href="https://www.inc.com/melanie-curtin/bill-gates-says-this-is-the-safest-age-to-give-a-child-a-smartphone.html" rel="noreferrer" target="_blank">https://www.inc.com/melanie-curtin/bill-gates-says-this-is-the-safest-age-to-give-a-child-a-smartphone.html</a>)<br>
and out of the box they can author youtube videos with it, but not software.<br>
<br>
At the other end conventional Linux development has the problem that "the<br>
average age of Linux developers is Linus' age" which is gonna bite pretty hard<br>
in another 10-15 years. The Linux Foundation has successfully purged most<br>
hobbyists from Linux development (in the US, Europe still seems to have some)<br>
and the ecosystem is getting WAY more complicated which means the barrier to<br>
entry for a basic understanding of what's going on without significant black<br>
magic and black boxes goes way up. (Last week chrome could talk to my website<br>
but command line utilities like ssh said no route to host, and I'm going<br>
"Running as different users... No. DNS cacheing... no. ipv6 routing vs ipv4?<br>
No... I was doing container stuff in another window, make sure that's cleaned<br>
up... no. Restart the wicd network manager... why did that fix it? Not a clue,<br>
but can no longer reproduce the issue so can't debug further, hope it doesn't<br>
happen again." Add systemd and selinux to that and I wouldn't know where to start.)<br>
<br>
I want to bring the ability to develop software to where people are. In the<br>
short term an app with the cartoony appeal of logo or quickbasic or visual basic<br>
or whatever java beans was trying to accomplish would probably be a better<br>
immediate solution. But I'm trying to solve the larger problem of making people<br>
with phones not be second class citizens to people with PCs: if there's<br>
something you can ONLY do on a PC and cannot accomplish on a phone, then the<br>
minority with PCs are still superior to the majority with phones. And if I<br>
expect PC volume to inevitably decline and phones to remain literally more<br>
common than indoor plumbing, that's not a good thing. Which is why I want<br>
Android users-turned-developers to be able to naturally expand their programming<br>
chops all the way to the bare metal.<br>
<br>
It is in that context that "you're a developer, you don't matter" hits me funny.<br>
Within the team Android is paying, as of today, sure. In the larger ecosystem,<br>
and in future, I really hope not.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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 :-)</div><div><br></div><div>(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...)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> the way to change that would be either reduce the cost (because upstream ends up<br>
> with something we can use, but that seems unlikely without us doing a ton of<br>
> work that no-one else would thank us for anyway) or increase the benefit ...<br>
> which brings us back to "you are not the user". i'm unable to come up with any<br>
> way in which devtmpfs would make consumers' lives better (or even partners'<br>
> lives), and given that opportunity cost is always important, i can think of a<br>
> ton of things those person-years could more usefully be spent on.<br>
<br>
I agree it makes perfect sense for Android to bounce devtmpfs for now. (The fact<br>
linux-kernel hasn't made devtmpfs useful to you is a failure of communication<br>
and a failure of linux-kernel, but that's a separate issue from Android staffing<br>
an engineering project.)<br>
<br>
> (obviously this would be different if the costs of the status quo were higher.<br>
> but like i say, right now afaik that's basically just this one hack.)<br>
<br>
Oh sure. But going forward, it's a todo item for me. "Can't fix now" != "won't fix".<br></blockquote><div><br></div><div>yes, it's quite clear you're in the other philosophical camp :-)</div><div><br></div><div>neither is wrong, but they're unfortunately quite incompatible in conversation.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Rob<br>
<br>
Rob<br>
<br>
P.S. Pascal's apology again. I still didn't manage to say the above in a<br>
reasonable amount of space.<br></blockquote><div><br></div><div>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... </div></div></div>