seniorgarcia

Just to point to another possibility, since the drivers right hand is not in shot, even though his left hand is carefully poised over the steering wheel for the whole shot, it also looks like he pulled hard on the steering wheel with his right hand.

That might explain the car trying to re-route on the display, although I'm not even sure it does. To me it looks like the black line disappears into compression artefacts at just the right time.

Mostly I think we don't have enough evidence either way and speculating just expresses our desire for the technology to work or not.

>>It feels like the height of arrogance and gatekeeping to look down on someone who just wants to be able to italicize or bold some text in their emails sometimes.

I really disagree with this part of your post. Plain text is just that, plain text. By definition there is no bold and no italics. We can talk about the the weird technical limitations and requirements for submitting inline patches all night if you like but I'm not sure what you are even complaining about aside from the technical limitations of plain text emails. If you think this is gatekeeping and it keeps you from expressing yourself I don't even know what to say.

Which is pretty interesting. Apparently Outlook mangles inline patches for the lkml as well to the point that they are unusable and that would have been an interesting talking point in and of itself.

But apparently talking about this is not in scope of this post and trying to piece together the issues just gets you downvoted so... Thanks for your advice, I was not aware that Gmail clobbers plain text mails, I guess there is more to it then getting your mail client to send plain text email. Maybe some explanation of the subject would have been nice.

Which is why I asked what the issue was and the author replied he/she was using Gmail/Apple Mail. I can see using the lkml with Apple Mail being difficult since Apple Mail sucks but sending plain text mails with Gmail should just work and nobody should have to change their email client if they are fine with using Gmail.

Even not using lkml, it's a standard conforming mailing list that (presumably) will accept any plain text mail just fine and I do not see why anybody would need to install a separate email client like aerc just to use this mailing list. So, to me it read "I know how plaintext emails work but for some reason my workflow does not work so I changed it to include something else" and I was curious as to why... Curse me for asking? Curse me for damning Apple Mail? Idk... I guess curse me for being curious and trying to help a fellow nerd out while shitting on Apple Mail at the same time.

Was my comment mansplaining? I'm genuinely curious.

Apple Mail sucks and I'm always shocked how many people think it's "good enough". All the Apple apps are barely functional but fall short when it comes to replace groupware (or actual standard compliant clients. Don't even get me started what Apple Contacts does to vCard).

>>I just think it's annoying that I had to change my perfectly good workflow that is enough to get me hired at large companies for this.

I don't get what workflow you are talking about.

I don't post to this specific list, so there might be weird issues I'm not aware of but...

Gmail has the plain text option behind the 3dot menu in the bottom right corner. Apple Mail deserves to die a fiery death and I refuse to support it but "Format" -> "Make plain text" *may* send a plain text message, or not depending on the OS X lottery. You can force Apple Mail with "Preferences" -> "Composing" -> "Message Format" -> "Plain Text" to compose plain text messages. Or you can use an actual mail client.

I'm kinda curious which client makes writing plain text emails hard though.

I do not dispute that you can use this in your app, my issue is with the server knowing about it (as it is in the demo here) and everything the server can call back from the client. It is not about airgapping but about realizing that current browsers can exfiltrate basically anything.

Your JS app wants to compute the amount of threads it can use on a client, that's great. If your JS app can calculate me switching browsers and using independent websites and their usage, that's cool. Why would you send that back to your server though?

If you do not think that current browser implementations have an issue with the amount of fingerprinting they can do, that is up to you as well. I think that the amount fingerprinting is at the very least difficult though. It is not about building native apps, it is about the amount of information that is send back. Or I'm drunk at this point and should go to sleep, I think I'm done in any case. Sorry about being an ass.

>Why does a webpage get to know how many CPU cores I have?

The question we have been replying too? Nobody gives a shit what you can do within the client. Fingerprinting the client as the host is an issue though, you might at least appreciate that...

And it is up to the client to manage all this. You do not gain anything by knowing the clients thread count. Which is what I have been complaining about all along.

And that is totally fine. If you don't care you don't need to know.

That has been my issue all along. Client computation of course needs to know how many threads are available to distribute computation in an efficient way. Why would the host need to know this though?

I believe that you think that your answers are true but my desktop will report 12, my work laptop will report 16, my macbook will report 16 as well, my work desktop will report 64 (my surface laptop will report 12 as well, my ipad pro will report 6... I can continue this for some time).

Which machine do you think has the best performance for your app?

Maybe you do not know what words in the English language mean? I have a Quest and an Oculus VR and a Samsung Gear VR and a shitty cardboard daydream.

I get how concurrency works. I do not get how you get any sort of useful information from my desktop claiming 12 threads, to my phone claiming 8 threads, to my quest claiming 6 threads, to my ipad/samsung tablet claiming however many threads over webxr.

I do not see how you can do anything useful with the thread count which is what I have been disputing. CPU thread count seems especially useless since it has no relation to VR performance.