HN user

chmike

2,567 karma
Posts132
Comments1,162
View on HN
news.ycombinator.com 3mo ago

High-Temperature Superconductivity of Pure Mg Metals, UFOs and Cuprates

chmike
1pts0
www.cs.cmu.edu 2y ago

Introduction to the Conjugate Gradient Method Without Agonizing Pain (1994) [pdf]

chmike
71pts15
news.ycombinator.com 3y ago

Explanation of Cold Nuclear Fusion and Biotransmutations

chmike
2pts0
www.youtube.com 6y ago

Destroying cancer cells using electromagnetic resonance frequencies

chmike
1pts1
medium.com 7y ago

Surely No-one Uses SSL v2.0 on their Web site? Yes millions still do

chmike
3pts0
octoverse.github.com 8y ago

The State of the Octoverse 2017

chmike
1pts0
medium.com 8y ago

The Morality of Manipulation

chmike
1pts0
www.indiehackers.com 8y ago

Hotjar: From two failed startups to $10M in Revenue

chmike
1pts0
medium.com 9y ago

3 Crucial Features of High-Growth Startups

chmike
2pts0
hackernoon.com 9y ago

We reverse engineered 16k apps, here’s what we found

chmike
3pts0
sourcemaking.com 9y ago

Design patterns, anti-patterns and refactoring

chmike
1pts0
rancher.com 9y ago

Rancher OS: thin os layer to run docker containers

chmike
4pts0
www.meessen.net 10y ago

Ball Lightning: Bubbles of Electronic Plasma Oscillations [pdf]

chmike
1pts0
tour.dlang.org 10y ago

D online tour

chmike
5pts3
twitter.com 10y ago

Multitasking is killing your brain and moral

chmike
3pts0
medium.com 10y ago

My Bathroom Mirror Is Smarter Than Yours

chmike
2pts1
vibed.org 10y ago

An introduction to vibe.d: Writing a scalable chat room service in D

chmike
20pts0
www.theguardian.com 10y ago

ProtonMail: encrypted email provider held ransom by hackers

chmike
1pts0
www.google.com 10y ago

Patent: Variable length integer encoding system and method

chmike
11pts1
news.ycombinator.com 10y ago

Why I will never again rate an Android app

chmike
20pts7
www.youtube.com 11y ago

Neutron bomb in Yemen?

chmike
2pts0
tommycarney.com 11y ago

What I learned validating my first product idea on an email list of 268 people

chmike
2pts0
www.youtube.com 11y ago

Jar Invention Lifts It All (Narrated)

chmike
1pts0
www.youtube.com 12y ago

Flying Robot Rockstars

chmike
1pts0
dave.cheney.net 12y ago

Resources for new Go programmers

chmike
1pts0
forum.dlang.org 12y ago

Facebook is using D in production starting today

chmike
365pts232
www.moodys.com 13y ago

Moody's reviews for downgrade five banks in Hong Kong

chmike
1pts0
www.coronaperspectives.com 13y ago

Viewing tennis ball trajectories in 3D

chmike
2pts0
ddili.org 13y ago

Programming in D

chmike
56pts40
news.ycombinator.com 13y ago

Fixing eBay?

chmike
3pts2

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

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).

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.

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.

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.

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.

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.

Thank you. It's the best argument against the certificate suggestion I have read so far. It's a problem I overlooked.

Edit: If the server creates the certificate with a three way handshake, it will use the remote IP address. So the client doesn't have to know it's IP address

I didn't mean to generalize the use of certificate. It would be for a specific protocol for a specific application. I just wanted to justify that we are not required to use three way handshake.

Revocation is indeed a weak point of this solution as it would take time, probably a transaction, to check. This problem might be mitigated by shortening the certificate validity duration.

I don't see why time synchronization would be critical if the validity periods are slightly overlapping.

In prior configuration, the UDP client must get a certificate which uses three way handshake to verify the IP address. Once a client has it's certificate, it can perform transactions with a simple two way transactions.

The problem result from the ability to forge a fake origin IP address. This can be avoided by adding a certificate for the IP address. It adds a processing and size overhead, but it also preserves the single round trip transaction.

Note: My comment is about communication restrictions and not about Imran Khan or Pakistan.

Restricting communication does indeed introduce a bias in information that people may get and thus the opinion they may forge. As such, freedom of communication is a pilar of democracy. But in some cases, communication may also be harmful and should be limited. Regardless if the info is true or false, if it may generate a harmful mass movement, it should be restrained. It's a bit more subtile than that, but I can't develop for conciseness.

I'm obviously talking about ebooks downloaded from commercial platforms like KDP Amazon, and distributed for free on Z-library without permission from the author.

Comparing this to your comment is whataboutism. Comments on hacker news are free to read. If you want to be payed for your writing, use a platform that support this.

However, you do have an automatic copyright on everything you write and I would need your permission (eventually by paying you a fee) to republish it in a book or somewhere else. Fair use is an exception to that, but the amount of text we can reuse without permission is limited. These are rules.

You steal the author's investment in time and effort to write the book and conceive it's content.

How you steal (making a copy) doesn't affect the fact that you prevent the author to get his share or reward from it.

These are pretty nice ideas fixing existing problems for desktop computers.

How would these work with mobile devices ? It doesn't seam compatible.

Also, these are user interaction suggestions. What about the encoding ? There are plenty limitations with Markdown (the pseudo standard) on this aspect.