ergl

You can actually use connect(2) for UDP. From the manual https://man7.org/linux/man-pages/man2/connect.2.html:

> If the socket sockfd is of type SOCK_DGRAM, then addr is the address to which datagrams are sent by default, and the only address from which datagrams are received.

After that, you can use send() instead of sendmsg(), so it saves you on having to pass the host on each call to sendmsg.

It can also avoid extra DNS lookups: everything is handled for you by the kernel. See also: https://stackoverflow.com/a/51296247

> Human activities actually cover very little land

51% of all habitable land is not "very little": https://ourworldindata.org/land-use#half-of-the-world-s-habi...

That's weird! I can't imagine why they would restrict certain options based on country.

> You can't choose Ubuntu and 32GB RAM at the same time.

You definitely can though https://imgur.com/a/tL10iNZ

> You can't even choose the top CPU option with Ubuntu, you're stuck with the i5.

You can select the i7-1260p option. Not the top one, but definitely not the i5.

"the same author wrote this"

That's not true though, the link you posted is authored by a completely different person.

What OP means with WhatsApp status is the photo/video stories that only last for 24 hours. What you're describing is now called the "About" section of your profile.

Skim pdf is a good option if you're on macOS: https://skim-app.sourceforge.io/

> Most of the repos have five to ten stars each, but if you open them up they are basically the same people over and over starring all the repos.

As a datapoint, this happens in a few of my repos. There's really nothing interesting in some of them (homework assignments from when I was in college), but there are a couple of profiles who star almost all my repos. I don't know them in real life, don't know where they came from.

You might be able to find research institutes or national labs (I'm a research engineer at one of these). If you're in Europe, something like the Max Planck Institute might fit the bill.

Aside, can I ask why you don't want to work at a college or university?

The performance characteristics of Rust and Elixir are completely different though.

It's weird to see "large messages" as a code smell. I'd say it's more of a thing to be aware about if you use any BEAM-based language: that's just how the runtime works.

But, if you're constantly sending large messages between processes, that might be a sign that those two processes are not as independent as you though, and it might be good to think if there's a way to merge them into a single process.

Another option might be see if you can transform those messages into ref-counter binaries, which will make sending messages quite cheap, since you're sending a single reference to the binary, instead of the whole thing. There's a tradeoff here, of course, depending on how expensive it is to transform your data into a binary, as well as increased complexity of garbage collection of these binaries.

OP mentioned git-bug, which seems to be this: https://github.com/MichaelMure/git-bug

Hi David, I've reached out via email with some questions. Thanks in advance!

Pony committer here, I don't think this comparison is very fair, Rust has way more users, and thus way more eyes looking at it and reporting bugs. We've also had a few runtime segfauts before due to LLVM (mainly when porting to new platforms, like Apple's M1), and we try hard to fix them when we find them.

You're thinking of Apple: https://news.ycombinator.com/item?id=30285682

Erlang has selective receive, meaning it will go through all your receive branches in order, until one matches.

With this code:

    receive
        {high_p, Message} ->
            process_high(Message);
        {low_p, Message} ->
            process_low(Message)
    end

if the process has one high_p message and a low_p message, the high_p message will be processed first.

The original surgery was also discussed here two months ago: https://news.ycombinator.com/item?id=29882912. The cause of death is unknown as of yet.

> I was really disappointed not to see the OneCoin cover for example.

I don't know if the article was updated, but you can see that covered right at the end.

If the maintainers have a good back-porting policy, they'd also put out a new 1.0.X release so that users of <1.1.0 can upgrade and get the fix without also getting the new function in 1.1.0.

This is something that Apple sometimes does for security updates on macOS: they'll release a new patch version on all supported versions.

It's not the case here (I think), but this can be common if you move functions around or expose functions that were previously internal.

For example, maybe your function is only called from another one that performs the appropriate bound checks, so checking again becomes redundant. After a simple refactoring, you can end up exposing your function, and screw up.

You can see a note under the text noting that it's a book excerpt: https://bookshop.org/books/sea-state-a-memoir/9780063030831

> It's surprising to me that this article, which was mostly about the life of a man on an oil rig, could inspire such discussion about divorce.

It's only surprising if you assume people read the story, instead of simply reacting to the headline. It's against the rules to say, but I'd bet the big majority of commenters never opened the link above.

To be fair your example would be unsafe with and kind of time API.

The APIs provided by TrueTime and Time Sync are useful to compare two events, each with their own uncertainty intervals. Then you can be sure if any event "happened before" the other, or if they're concurrent.

> If you can still have two actors waiting on one another

There's no way to actively wait for another actor (except for using callbacks). The only way for your situation to occur would be if one of the actors receives a message with an included callback, but decides to never call it.

For all you know your Signal contacts are using a CLI client and then forwarding the messages through SMS to their feature phones :^)

> That's common sense. We all know who are protected classes. For instance, members of board of directors of the big corporations are a protected class.

Uh… is this a troll? Like other commented said, this feels like a anti-CoC thing or an extreme case of Poe's law, at least.

>There is no reason for it.

The reason is that bits are not physical. Anyone can copy them and re-upload them, without any cost.

> [I]magine two submissions with the same number of upvotes and a different number of views. The article with more views probably has a lower quality than the one with fewer views, because more people have viewed it without giving an upvote. So the ratio of upvotes and views is a signal of quality.

I believe this creates a bias against longer articles. If a submission links to a longer piece, a user could take a long time to come back to HN to upvote the submission.

That's not to say this would be any worse than the current algorithm. By definition, a time-ranked frontpage and moving discussion will always favor shorter articles, or, if the content is long, produce plenty of comments that are only superficially related to the article.

As a submission ages, its rank wanes, and discussion gets more sparse: a piece that takes time to read, understand and digest will probably perform worse than a short one, since the discussion and votes will take place further into the future.

> Dealing with RDMA aware networking is far beyond the ability of typical web developers.

Homa is designed for traffic inside a DC, same as RDMA or Infiniband. I don't think anyone is proposing to use it for normal web traffic.

Signal uses local networking for the account migration functionality: https://support.signal.org/hc/en-us/articles/360007059752-Ba...

You scan a QR code with one device and it transfers the entire account state to the new phone.