Hacker Newsnew | past | comments | ask | show | jobs | submit | wizerno's commentslogin

Another great read on futexes is Ulrich Drepper’s paper "Futexes Are Tricky" [1].

[1] https://cis.temple.edu/~giorgio/cis307/readings/futex.pdf



Does anyone else miss the functionality of the Android WhatsApp widget [1] on iOS? Being able to read messages without sending read receipts via the widget is a great feature. The iOS notification 'peek' is a clumsy substitute.

Is this a fundamental limitation of iOS widgets/APIs, or just something WhatsApp hasn't implemented? Curious if others have found better ways to handle this on iPhone.

[1] https://www.tomsguide.com/how-to/how-to-use-the-WhatsApp-wid...


Long-pressing the chat in your thread list gives you a quick preview seemingly without sending read receipts.


It is implemented in the app itself. WhatsApp > Settings > Privacy and turn off Read receipt.


The use case is slightly different. I prefer to send read receipts, but I also like to peek at messages without sending them and removing unread counts because I want to add the message to my mental queue, but don't want the false impression that I didn't bother to answer the said message.


Ah, you want to read messages without letting the recipient know you've read the message, while still having read receipts enabled. I'm not surprised WhatsApp does not support this one, I think they want their users to be able to trust the read receipt indicators


Actually it supports that, via notifications and peek. The intent is not nefarious, as I said before. I don't want the person who sent me the message think that I read their message and just tossed to a virtual bin.

I just did it yesterday. Somebody sent me a message, and I read it via notification, but they don't have the receipt yet. I'll write their answer with a fresh mind, and send the answer they deserve.

I don't think valuing the person on the other end of the line is a bad thing.


> Being able to read messages without sending read receipts via the widget is a great feature.

More like an unfair anti-feature


Hm? Should I as the user not be able to decide what I send or don't send?


You can disable read receipts in the settings, but then you won't see their read receipts. This is fair.


It looks like you're correct -- Gregglogger relies on pynput, and its behavior on macOS aligns with the library's documented limitations [1]:

Recent versions of macOS restrict monitoring of the keyboard for security reasons. For that reason, one of the following must be true:

- The process must run as root.

- Your application must be whitelisted under "Enable access for assistive devices." Note that this might require packaging your application, since otherwise the entire Python installation must be whitelisted.

- On macOS versions after Mojave, you may also need to whitelist your terminal application if running your script from a terminal.

[1] https://pynput.readthedocs.io/en/stable/limitations.html#mac...


I wonder if they'll index more repositories over time. As it stands, there's no clear way to tell what's indexed versus what's not. A transparent way to see the scope of coverage would be incredibly helpful for users.


The author has a few blog posts covering the tee, split, which, and cat commands [1].

[1] https://www.anardil.net/tag/coreutils.html


John Oliver discusses how so many people have come to take on student loan debt, why it’s so hard to pay off, and what we can do about it [1].

[1] https://youtu.be/zN2_0WC7UfU


As someone who's fascinated by formal verification and who's early in their career, what advice do senior folks who have been using TLA+ have?

TLA+ isn't taught in most universities and while I've read about so many interesting applications, I'm yet to convince myself that someone would hire me for knowing it rather than just teaching it to me on the job. Any tips to get started would also be appreciated!


There's very little tech that somebody is going to hire you for knowing. It's a tool like many others.

If nothing else, spending a few days playing with it will give you an idea of what it's good for and if you want to continue, or it'll make it stick in your mind so you can come back to it if you ever need it.


>There's very little tech that somebody is going to hire you for knowing. It's a tool like many others.

I guess this must be true on places like SF since I see this so often on HN, but almost every single job listing I've seen strictly requires knowledge of a specific tech stack, with the exception of a few internship programs.


There's tech that if it's not on your resume, you won't pass the first filter. But that's different. Knowing it will _not_ get you a job, it'll just get you past some early step.

But things like TLA+ are way different from even that. The number of programming jobs that will bin you if you don't have TLA+ on your resume has to be like, 5 in the world. Nobody is going to see it on there and be like "we _must_ hire this person!".


Exactly my thoughts as well.


Someone might hire you for the things you did with it, or for the passion you showed by learning it.


As per RFC 3986 [1], reserved characters such as , and / must be URL encoded.

, is encoded as %2C

/ is encoded as %2F

[1] https://www.rfc-editor.org/rfc/rfc3986


That's not the question. The question is what if you have an open ended URL param that can also have subpaths?


A slightly related discussion on Type Unions in C# from a week ago: https://news.ycombinator.com/item?id=41183240


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: