Hope I'm not the only one that clicks on the link mainly because I'm curious to know how they "conducted" such a study. From what stated in the article, is it safe to assume that this has happened only once, ever?
Readit Newshuynhhacnguyen commented on Evidence that life flashes before the eyes upon death hyperallergic.com/720694/... · Posted by u/relaunched
huynhhacnguyen commented on Evidence that life flashes before the eyes upon death hyperallergic.com/720694/... · Posted by u/relaunched
Wait, I thought the purpose of life flashing before your eyes is that the brain is trying to find a past event, that might help avoid the impending death. On QI, though I cannot remember the episode, they told a story of a swimmer, who encountered a shark, and suddenly his life flashed before his eyes, thinking he was going to die. In the slides of memories, he saw his son watching a DVD about punching a shark on the nose. So he did, and it saved his life.
That explanation makes a lot of sense to me. The brain is convinced that death is imminent, and has no time to go through the normal procedure of remembering, so it just pulls up as many memories it can to the forefront, in hope that one of them might provide the answer to prevent death.
That is indeed a convincing argument, and has been portrayed in various contexts, one of which is BBC's Sherlock when ... (oops, spoiler). However, there was no further explanation as to why there is an evolutionary pressure for the brain to do this trick, AFAIK.
huynhhacnguyen commented on Launch HN: Reality Defender (YC W22) – Deepfake Detection Platform · Posted by u/bpcrd
Thanks for your questions.
- The input to our models are image, video, and audio. Based on the model, we can use parts of the image (esp faces) or whole image. Yes, we also incorporate metadata for better detection.
- It's a fair concern. As quality of generative media increases, so does the sophistication of detection. Since, we fully understand how generative media is created, it gives our the leverage to reverse engg. Much like the anti-virus industry (wrt scanning), we'd need to be at the forefront of not only detection, but generation methods, re-learn models based on new generation methods, etc.
Thanks for the response, I'll look more into this. So what you're saying is we need to understand the methods to devise countermeasures to such methods, instead of being model-agnostic. That sounds like a grueling task and truly an arms race. Best of luck to the team!
huynhhacnguyen commented on Launch HN: Reality Defender (YC W22) – Deepfake Detection Platform · Posted by u/bpcrd
First of all, congratulations on the lauch! Your description about the "model of models" and combining their scores is really intriguing. Detecting deepfake is an interesting topic on its own and apparently there are lots of use cases that I'm not even aware of, partly due to my limited knowledge in this subject. There are a few points of I'm curious about (Beware that the following questions can be very silly, coming from someone having little to no experience in the field):
- What do you use as input for the model? Does it use all the pixels in all the frames in the input video? How about the video's metadata (location, extension,...)?
- My biggest concern about fighting deepfakes is that they have a point to achieve where the line between reality and fiction is nonexistent. Namely, if a deepfake video of someone can be created to look exactly like a real one if that someone decide to record such a video, I imagine there would be no way to tell the deepfake video from the authentic one (since there is no difference between the two). Because of that, this looks like a losing battle to me, but maybe I'm just too pessimistic. Do you feel that it is a real problem? Do you believe it is such a long shot that we shouldn't be worried about, or even if things reach that point, there would still be tools in our arsenal to counter such technologies.
huynhhacnguyen commented on Please put units in names ruudvanasseldonk.com/2022... · Posted by u/todsacerdoti
if you type check, then it ensures that only a 'second' can be passed to the function. This requires you to either create a second, or explicitly cast to one, making it clear what unit a function requires.
As per the article, if you dont have proper names and just an 'int', that int can represent any scale of time...seconds, days, whatever.
In python youd need something like mypy, but in rust you could have the compiler ensure you are passing the right types.
Having a type system to figure this out for us would be great, but there are languages where this may not be possible. As far as I know, Typescript is one such example, isn't it?
huynhhacnguyen commented on A better way to divide the pie insights.som.yale.edu/ins... · Posted by u/geox
In general: Suppose the fallback positions are x slices for Alice, and y slices for Bob, and they get n slices total if they reach a deal. Then we can figure out the split by defining the gain, g, as the additional pieces they get if they reach a deal. So g=n-(x+y). Then the fair split should be x+g/2 for Alice and y+g/2 for Bob.
Another kind of situation is if there are 3 people, Alice, Bob, and Charlie, with fallbacks x, y, z respectively. Suppose they all need to reach an agreement to get n slices. Then g=n-(x+y+z) and Alice, Bob, and Charlie should get x+g/3, y+g/3, z+g/3 respectively.
Another possible situation is if there are 3 people, but they have unequal roles. Alice only needs to make a deal with at least one of Bob or Charlie, to get n slices. If Bob and Charlie both agree to the deal, then the total is still n slices. Intuitively, this would make Bob and Charlie less important, so they should get less of the gain. The split here should be x+2g/3 for Alice, y+g/6 for Bob and z+g/6 for Charlie, if they're all in on the deal. The reasoning there is that if we're adding games together, then we should also add the payoffs together. We can make a Alice&(Bob|Charlie) game by adding together Alice&Bob + Alice&Charlie - Alice&Bob&Charlie. Similarly, the payoffs should add like this: (g/2, g/2, 0) + (g/2, 0, g/2) - (g/3, g/3, g/3) = (2g/3, g/6, g/6)
Wow thanks for the very detailed explanation, mate, that is much appreciated. However, I still wish the author had delved into more real world examples, to let us have more sense of how this principle can be applied into more practical use cases. "Algorithms To Live By" https://www.goodreads.com/book/show/25666050-algorithms-to-l... did a really good job at that. Of course an article cannot be at book length but a man can hope.
huynhhacnguyen commented on A better way to divide the pie insights.som.yale.edu/ins... · Posted by u/geox
If we can ignore the utility value of the negotiating pie (e.g. Alice may not want a 5th slice anyway), it is an interesting perspective. If only there were more examples and less explanation.
huynhhacnguyen commented on Luisa – Turn Figma designs into Vue apps luisa.cloud/... · Posted by u/klausschaefers
Do you have any example UI code that was generated by Luisa? It would be interesting to see how the issues that have been plaguing low code tools since the beginning of time including absolute positioning & element hierarchy.
> I think the general idea is for the company (and other employees) to give employees what they want and recognize how they want to work. If someone prefers working at the office, it would be terrible to force them to WFH.
> Regarding productivity, if someone does their best work at the office communicating with other people but prefers working at home, wouldn't they fall behind their colleagues when they opt for a WFH setup?
Generally agreed, but caveats apply here: a lot of folks may prefer to work from home, but don't necessarily prefer the approach that leads to their greatest productivity. Also, most people don't properly account for intangibles, such as the creativity benefits of an environment where people spontaneously interact on a daily basis (it's famously the entire reason the Pixar studio building is designed as it is), or the mentorship of new people. Costs like this may be OK for a year, or three, but will eventually come back to bite you.
Finally, many people have reliably mis-aligned notions of what "productivity" is. For example, when a junior engineer disappears down a dark hole of code, it's usually a bad sign, even though they almost always think they're being very productive (I say this from deep personal experience, having fallen into this same trap many times over). The danger of this one is that even if you're evaluating by "outcome", nobody really knows if you're unproductive because you're drifting, or because you're distracted, or because of something else. And if you're far from the group, it's even harder to tell what might be wrong.
Remote work feels bad for junior employees, for exactly this reason. So many times in life you're stopped from going down a dark path not because of a meeting or a status update, but because you started chatting with the other people on your team over lunch, and found out that Bob had an idea the other day that would make your change ten times easier to implement, and Alice was refactoring some other bit of code that solves the bigger problem. And oh yeah: haven't you heard that the manager of the Chaos team is talking about eliminating that use-case anyway? Spending too much time there would be toxic for your career!
I haven't found a way to replicate this with zoom.
The point about junior employees is reasonable. In such cases, we may have to find ways to really mentor them, not just to evaluate their performance, so listening and understanding their struggles would be of utmost importance. During a 6-month period when we had to adopt a full WFH mode, I've had to conduct a dozen sessions like that, and had some promising results so far, so progress while small are made. In time, even though they may not be able to improve on all their shortcomings, they start to realize when they need to reach out to other experienced members of the team or when to raise their concerns. Anyway, the point of working remotely is not to eliminate communication but to filter out the necessary from the distracting ones. That being said, a team consisting of mostly freshers will surely fall apart in either a WFH or an office setup.
huynhhacnguyen commented on On the Weaponisation of Open Source beny23.github.io/posts/on... · Posted by u/beny23
We look at the behavior of packages, what APIs they use, and how that changes over time. The list of issues we currently look for is here: https://socket.dev/npm/issue
Socket’s not open source at this time, but we’re releasing a CLI in the coming week if the GitHub App doesn’t suit your purposes.
That's actually interesting, I will look into more details to see if we can integrate this into our systems. Do you have any avaiable technical documents so we can get a glimpse of how Socket is working, or is your Blog the best place to start?