Because that isn't open source, and is arguably not enforceable anyway.

How do you define "make $1M"? There are mega corporations with billions in revenue that somehow have a negative tax bill each year, so clearly taxable income isn't a reliable indicator.

Conversely a non profit organisation may have several million in donations/income but spend all of it on their charitable causes.

So clearly net revenue isn't a reliable indicator either.

If you don't want to release software under a licence without monetary terms, then don't. No one is forcing you to do that.

> the llm doesn't make good long term decisions

What could possibly go wrong, using something you know makes bad decisions, as the basis of your learning something new.

It's like if a dietician instructed a client to go watch McDonald's staff, when they ask how to cook the type of meals that have been recommended.

AI is great at exposing you to what you don’t even know you don’t know: your personal unknown unknowns, the complexity you’re completely unaware of.

> llms can get me started really fast. Basically it distills the time taken to research

I was saying that it speeds up research by exposing you to the things you don’t know that you don’t know.

Or the things that it has hallucinated, or just referenced incorrectly.

That's my point. You're talking about learning basic maths from a school teacher who isn't a Calculus expert, but the thread is talking about learning maths from a kid with ADHD who completes the homework before the teacher has finished describing what needs to be done, but sometimes returns homework in an invented language with references to Cthulhu throughout it.

Why are GrapheneOS releases dependant on Google releases?

I have trouble understanding why this is different on mobile devices. People keep speaking of blobs but that doesn't seem to be a thing in laptop/desktop hardware, unless they mean something like the firmware running on your wifi card and uefi chip? But those can be interfaced with from any kernel version, afaik, so I don't get it

That's a dependency: if you want your system to be secure, you depend on the software running on your system to be patched when a security flaw is published.

The attack vectors against this firmware are virtually always physical right? As in, hardware access in one way or another (including radio waves reaching the device), not something that can be routed over a (cell) network

If you have an EOL Pixel and a new major version of Android is released, Google will not port this new version of Android (and therefore AOSP) to it. So GrapheneOS would have to do it. GrapheneOS just say they don't have the resources to do that, so they follow the Google releases. Could you keep an EOL Pixel without receiving updates? Sure. But then it's not supported anymore, it's just outdated, insecure software.

> I'm not even really sure what you mean by "manufacturer updates".

There are the AOSP updates (which bring new features, but importantly in our case bring security fixes) that come from Google, but your phone is more than that. There is a bunch of hardware running in your phone and a bunch of firmwares exposing it. Say your camera, or your wifi module, etc. If there is a security issue in the firmware of the camera, then it won't be fixed in the AOSP codebase. You need the camera manufacturer to fix it and release a firmware, pass it to the phone manufacturer who will then deploy it on your phone.

Google split both of those concepts years ago in order to deploy Android updates faster and make everybody more secure, because manufacturers had a tendency to lag a lot. Some still do but the situation generally improved, I think. Anyway, you need to receive those security updates from your manufacturer because they are independent from Google.

> the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest.

If you think that AOSP is shit, then sure. I mean, if you think that the Linux kernel is shit, maybe you don't want to run a Linux distribution.

I personally think that AOSP is pretty great, and vastly superior to Linux on mobile (among other because it has a much better security model). I am not a big fan of Google being root on my phone (with Android and system apps like Play Services), which is something that GrapheneOS fixes (by making Play Services run like any other, unprivileged app). GrapheneOS is also adding privacy features, be it by proxying your location requests (so that they go through the GrapheneOS servers instead of directly to Google) or by adding features like "scopes", where you can choose exactly which contact you share with an app, for instance, or refuse Internet access to an app without breaking it (GrapheneOS will just make the app believe that it has the permission to access the internet but there is just no connection right now). And of course GrapheneOS hardens the system in terms of security (e.g. with a hardened malloc or memory tagging stuff that Apple recently introduced as well).

So yeah, it is relatively thin, because AOSP is a huge codebase. But it doesn't mean that it's worthless: this skin makes it more secure, more private, and for me more enjoyable than Android.

I think breaking away from open source Google code is not really meaningful. It's kinda like saying "I don't want to run Linux because it contains code from IBM/Google/Meta". AOSP is a great and useful project. If the day that Google stops releasing AOSP ever comes, a consortium of interested organizations can fork it. But it does not make a whole lot of sense to start a new mobile ecosystem completely from scratch, if one that is great and open source already exists and buys you compatibility with millions of apps.

NFC is by far more convenient and reliable.

QR codes are reliable.

NFC (EMV) works offline.

It's pretty common here that people will be told they need to turn off an otherwise working Wifi connection when facing problems because bank apps will often just not work properly on wifi.

But as I said, even without that, the convenience level is ridiculously different. It's arguably quicker to open your wallet and use a debit card with an NFC chip than it is to use QR codes, before we even talk about the convenience of watch/phone payments using NFC.

Got it, that's a fair point!

> But as I said, even without that, the convenience level is ridiculously different. It's arguably quicker to open your wallet and use a debit card with an NFC chip than it is to use QR codes

This part sounds like those people who use a different unit system than I do and explain to me how my unit system is objectively more inconvenient than theirs. To which I answer: "I think I know better than you what is more convenient for me, given that I use it everyday" :-).

I use QR codes instead of opening my wallet, which kind of hints towards the former being more convenient than the latter for me. And for the millions of people who also do that.

I'm not saying "yours" is less convenient. I'm saying the one you and I both use regularly is less convenient than anything NFC based, which I also use semi-regularly.

> It's arguably quicker to open your wallet and use a debit card with an NFC chip than it is to use QR codes

So I assume that even though QR codes are available where you live, you use your debit card with an NFC chip because it is quicker than using QR codes...

Anyway, the important part is that NFC doesn't require an internet connection, and I had missed that. Now I wonder why a QR code couldn't work without an internet connection just the same. I'll have to look into that!

Yes, I generally use my card rather than than QR unless the shop doesn't take cards, doesn't have a paywave/etc-enabled card reader, the card reader is broken, the sales person doesn't know how to use it, or the sales person insists I give them my card and PIN to pay (none of those are hypotheticals, I've experienced all of those first hand, some of them quite repeatedly).

> Now I wonder why a QR code couldn't work without an internet connection just the same.

Because a QR code is just a short piece of information to tell your banking app who to send funds to - it's like putting a mailto: link on a website rather than asking people to re-type your email address to contact you.

There is already a way to put html, js and styling in a single file, and it was all the rage around 1997-2000, the last time humans were routinely using shitty software to generate code for them.

It took quite few years for people to learn those mistake the first time.

Horses for courses. I'd prefer to just have a regular file I can tail or grep or whatever, out of the box.

why would i inspect this data, because maybe trying to find a cause to a problem.. are there any other reasons

Turning on logging is likely more useful. Have done that to understand inner workings of some financial apps.

So uh, don't do that.

You don't need to notify if you use cookies for required functionality like login sessions or remembering a functional setting.

If you're tracking whether they're returning or not your activity is exactly the kind of behaviour the rule is covering because, in legal terms, it's skeezy as fuck.

Nobody wants to be the EU test case on precisely how "required functionality" is defined. Regardless of what the plaintext of the law says, it should be self-evident that companies will be more conservative than that, especially when the cost is as low as adding one cooke banner and tracking one preference.

https://gdpr.eu/cookies/

If your legal team genuinely suggests that, it's likely your company uses the login cookies for some additional purposes.

To put a finer point on some of this, in one instance, I was writing an application that would allow our customers to deploy their own website with content that they had created through the tool that my company had provided. My company wasn't adding any tracking whatsoever to these pages. We were simply taking their content, rendering it properly, and hosting it for them. We ended up enforcing a cookie banner on these pages because the lawyers couldn't guarantee that there wouldn't be tracking content on that page that was added by the customers. But the end result is that every page, the vast majority of which don't have any tracking, still have cookie banners.

In essence, the law created a new legal hazard, and people aren't sure when they're going to run into it, so they end up putting up fences all over the place. Between this and malicious compliance, the end user experience has suffered greatly.

So a generic cookie banner is actually going to make the legal case worse than not having one at all (because you've now demonstrated that you knew you should have explicitly declared usages, partners, and used opt-in consent, but you didn't).

I can't tell what's worse:

- they now expect people to actively work during the commute they aren't paying you for; or

- they're perfectly fine setting an expectation for people to work while commuting, ignoring the obvious safety issue that presents for anyone whose commute involves a car, walking, or crossing a street.

I think it's worse that a CTO doesn't seem to know the difference between a PR and an app.

I would be more surprised if these people did understand what a PR is. $50 says this fucker doesn't know the difference between Git and GitHub either.