Readit News logoReadit News
drac89 commented on OpenAI, the US government and Persona built an identity surveillance machine   vmfunc.re/blog/persona/... · Posted by u/rzk
MattDaEskimo · 17 days ago
What can those do from a separate country, who unfortunately had their identity verified through Persona (LinkedIn in my case).
drac89 · 17 days ago
From the blog post I've recently read; https://thelocalstack.eu/posts/linkedin-identity-verificatio...

1. Request your data. Email idv-privacy@withpersona.com or privacy@withpersona.com. Under GDPR, they have 30 days to respond.

2. Request deletion. The verification is done. LinkedIn already has the result. There is no reason for Persona to keep your passport scan and facial geometry on their servers. Ask them to delete it.

3. Contact their DPO. dpo@withpersona.com — that’s their Data Protection Officer. If you want to object to them using your documents as AI training data under “legitimate interests,” this is where you do it.

4. Think twice before verifying. That blue badge might not be worth what you’re trading for it. A checkmark is cosmetic. Biometric data is forever.

drac89 commented on Show HN: Real-Time Gaussian Splatting   github.com/axbycc/LiveSpl... · Posted by u/markisus
tough · 10 months ago
Apple Vision maybe?
drac89 · 10 months ago
maybe
drac89 commented on The Lost Art of Commit Messages   seyhan.me/blog/post/lost-... · Posted by u/drac89
tobyhinloopen · a year ago
--message "wip"

Why do we care about commit messages? I only read them when rebasing.

drac89 · a year ago
It's useful in case like if you ever need to fill out a PR template with what you did or list the changes, it becomes so much easier. You don’t even have to remember exactly what was changed it’s all right there in the commit message.

With structured comments, you can even use the AI to fill out the PR template easily and precisely.

drac89 commented on The Lost Art of Commit Messages   seyhan.me/blog/post/lost-... · Posted by u/drac89
occz · a year ago
I'm not sure I'm entirely on board with this particular format, but I do agree with the larger point of well-crafted commit messages - and commits, for that matter - being an important quality feature in a project.

I'd posit that well-structured commits are principally for the benefit of the reviewer of the code. Order your commits in a fashion that makes sense narratively, and give them meaningful commit messages. Use interactive rebasing liberally if need be to accomplish this goal.

As a reviewer, you are well within your rights to decline a PR that consists of a single non-meaningful commit message and a +/- 1000 lines diff. Effort is expected from both parties in checking in code.

drac89 · a year ago
And the best part is, if you ever need to fill out a PR template with what you did or list the changes, it becomes so much easier. You don’t even have to remember exactly what was changed, it’s all right there in the commit message.
drac89 commented on The Lost Art of Commit Messages   seyhan.me/blog/post/lost-... · Posted by u/drac89
Cthulhu_ · a year ago
A one-liner: sure. A ticket? No; ticket systems are transient and not always available. You shouldn't need to open an external system that may no longer exist in 20 years time (for example) to get the full context.

Compare the Linux commit history, every commit has its full context and explanation and they do not rely on external systems.

drac89 · a year ago
I agree maybe not adding the ticket link is better if you know that the system might not be available in the future.

You can not avoid it all the time but maybe It's better to use the PR description for that purpose.

drac89 commented on The Lost Art of Commit Messages   seyhan.me/blog/post/lost-... · Posted by u/drac89
Hojojo · a year ago
I quite like my current system.

One word naming the topic or area or system that was changed, then colon separated with a very short sentence giving a summary of the changes, then two lines later (if necessary), a bullet point list of the most important/noteworthy changes, then an explanation for why a thing was changed (if any change in the commit warrants it).

Honestly, I know most people won't go beyond the first line, but I do find the rest of it very helpful for my own work if I have to go through the commits sometime in the future.

It also helps that most of it is optional and I decide on a case by case basis whether just the first line is sufficient or I need the whole thing.

I see in the comments people questioning the purpose of a bullet point list, but it actually is helpful. I don't want to have to check the diff for every single commit if I don't have to. It's time consuming. If a commit message can tell me immediately if it touched something I'm interested in, that's a big time and effort and mental bandwidth saver.

Example:

auth: Refactored and fixed edge cases

- Fixed incorrect handling of token groups

- Added role enum to replace static strings

drac89 · a year ago
Looks beautiful. And the best part is, if you ever need to fill out a PR template with what you did or list the changes, it becomes so much easier. You don’t even have to remember exactly what was changed, it’s all right there in the commit message.
drac89 commented on Imagen Video: high definition video generation with diffusion models   imagen.research.google/vi... · Posted by u/jasondavies
drac89 · 3 years ago
The style of the video is very similar to my dreams.

Does anyone have similar feeling?

u/drac89

KarmaCake day89March 18, 2013
About
@drac89
View Original