Recent submissions

Comment · 2 months ago
> I don't get it

Is it hard to understand that for some people it may be difficult to read ? It might be due to motivation issues, thrust issues, or concentration issues. While at the same time they may have a rich inner imagination or thinking that they would like to share.

My impression is that humanity might miss valuable insight by rejecting whatever is not "well written" whatever the reason might be.

You may feel yourself very luck if you don't have any difficulties to read and write. Avoid to judge severely people who don't share the same facilities.

Comment · 1 year ago
How does mox compare to maddy, another Go all in one mail server ? Does mox support antivirus addition ? Didn't see that in the docs but I may have skipped that section.
Comment · 2 years ago
humor: I wonder if the upvotes are cheerings that he finally stepped down or a respectful salute. I give my respectful salute.

Go is awesome and I hope it will continue to progress in that direction. Thank you Russ Cox

Comment · 2 years ago
While I agree that we're not there yet, I'm one of the people who assumes that it is feasible to beat humans intellectually.
Comment · 2 years ago
The problem is not being unpaid. The problem is lack of verification and control, which itself result from lack of help and participation. You won't fix these problems by throwing money at it.
Comment · 2 years ago
And human generated data may not ?
Comment · 2 years ago
What I don't understand is why computers and operating systems have not adopted the TAI as time reference which is monotonic, etc. Time is a complete mess.
Comment · 2 years ago
I would have tried parallelism just by curiosity. Split and spread the computation over multiple cores. If you have n cores you could get close to a factor n increase minus the cost of spreading the data and combining the results. That's an easy optimization right out of the box with go (no assembly required).
Comment · 2 years ago
It depends on the distribution of probabilities of being used. If least recently used data has the same probability to be requested than the others, then random picking will do as well as LRU.

When the least recently used data does have a lower probability to be requested, than LRU will outperform random picking.

There is no silver bullet algorithm.

Comment · 2 years ago
The peer review system is definitely biased. It's ok for many articles, but there are outliers. For instance really original theories or experimental data. The publication may be stopped to avoid putting the journal's reputation at risk or because the reviewers have personal reasons to not support the article (it would shade their own pet theory, invalidate their research project, they didn't understood it, etc.).

The problem with publishing elsewhere is that many people unable to objectively evaluate the validity of the theory juge its value by the reputation of the journal. Also the other journal will most probably have less visibility. There is thus a higher chance that the other theory will not be reported in reviews.

There are many assumptions in the above comment that I can't agree with. But my experience is with physics, not computer science.

Comment · 2 years ago
The effectiveness really depends on the request pattern. In some use case, the LRU is the most efficient. When it is purely random, it obviously won't be the best as any value has the same probability to be selected.

Regarding simplicity, there is a simpler algorithm where we don't need the next and prev pointers. We simply replace the non-flagged value at the hand. This is most probably what is used in CPUs.

Comment · 2 years ago
A close up section of the same zone in the images would make them visible. I could hardly see the artefacts in the first place as my attention was caught with the highly contrasted parts of the images.
Comment · 3 years ago
I suggested the certificate solution but it's far from being lightweight. I found a simpler solution that may fit some use cases.

The client sends a request, the server returns a response that may be big that also contains a random value. The client must return this random value in a thank you message.

If the server doesn't receive the thank you message, it slows down responses to that ip address and eventually blacklist it if it's repeated.

From the client perspective, the answer is obtained in one round trip time. The price to pay on the server is the need to keep track of the expected thank you messages, and the throttled or blacklisted addresses.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton