andrew-lucker

pagerank works both at the domain and page level, originally with the emphasis on page level(hence pagerank not domainrank).

While it would be hard for these sites to match the cumulative reach of SO, they will have an easier time getting specific pages to rank highly. This can also be abused with a system where most pages link to the .1% of pages that should be emphasized. In this fashion, smaller sites can throw their weight around and get specific pages to rank more highly than bigger sites.

Trying to solve this issue on a purely technical level turns out to be a lot more complicated than it would seem. It is made much worse by how damaging false-positives are for a search engine (Google censored me!). So the result is that this often only gets resolved by manual actions rather than automatic penalties.

And about as useful as HTTP 302. fork fork fork... what standard?

Computer Science is to Programming what Anatomy is to realist painters.

No, learning anatomy will not make you a good painter. However if you are already a painter and want to become great, then you will need to learn anatomy.

So if we want to get pedantic, "random chord" is undefined here, which means that all the methods presented in the article as well as my sampling methods, and even the 0 and 1 case are all technically correct probabilities.

For example one of the most relatable alternative probabilities for me are, now thinking about it, actually the 0 or 1 cases: spinning a compass will generate a randomly oriented chord inside the face. What is the probability that the chord is of length > sqrt3? 1. Is this result informative or useful? no.

The result is that there are different generating functions with different biases which may or may not be useful. The three sources of randomness in the article correspond to physical stories that are possibly useful, and as such relatable. Otherwise they are no more legitimate than my absurdist examples.

Accepted! Now let's derive almost any "probability" from almost any deterministic variable through arbitrarily bad sampling methods...

Choose a goal probability B in the range (0,1). It can't be at 0 or 1, but can be arbitrarily close.

Now let's start sampling, and we'll take this all the way to the limit. For any discrete sample size as sample size goes to infinity, let's choose some positive/negative outcomes such that our probability approaches B. Remember that because our goal probability is greater than 0 and less than 1, there are infinite positive/negative outcomes to choose from.

This distribution has some interesting properties. The derived probability is B. The sample will grow to include all points. There are infinitely many functions to generate this outcome.

On most discrete samples for the 1/4 or 1/2 case, the probability of choosing any two points in the subset may be uniform, but the location of the permitted points is definitely not. If you add the requirement that all discrete point samples should be equidistant, then you fix yourself on 1/3 and there is really no way to break that conclusion.

Sorry, in this case "uniform" is ambiguous and I didn't mean the usual definition related to probability, but rather to point spacing.

There should be infinitely many "solutions" to this if you are allowed to define the sampling method arbitrarily.

Intuitively, one would think that random points are uniformly distributed, but that is not maintained in two of these solutions. If you randomly generate two points in [0,2pi) with a uniform distribution then you will quickly get the 1/3 probability empirically or provably by the limit.

However, if you are allowed to derive the second point from the first (such as the cross section example) or create some other dependency, then you are given great liberty as to what the resulting "probability" will be. Sure you can even guarantee that every two points on the circle will be present "eventually" but infinity is very large and how you approach it will determine your eventual outcome. Here we could subsample preferred points first and actually derive any specific probability (0,1) and maybe even make it sound reasonable. This behaviour will even be maintained into the limit, but it is certainly not intuitive, at least to me.

Nagios is pretty standard for monitoring.

Administration is usually custom automation. There are a lot of tools for this, and they all have good and bad, so you should just go with what is most accessible to you.

This should depend on your field, because some are more gated than others. If you are lucky enough to pick an open one, then you can find good work published and available online.

In my case, I work in an open field. To find new work I simply identify thought leaders and start following their careers. Work happens pretty slowly, so checking in once or twice a year is usually enough to see whats happening and what is in the works.

Just stop it.

Seriously though, you learn a new human language and jump into one of the most intense fields of study and start having an inferiority complex? With that attitude you'll need to be world renowned before you have confidence to speak in public.

If there is anything I can do to help, as a native English speaker with programming/CS experience, my email is in my profile. Best of luck.

MD5 is good enough to prevent most random collisions. The problem is when you need to prevent intentional collisions.

Would you run a stock-picker algorithm that never did backtesting? Real data-science is much more complex than just applying "this should work" reasoning and jumping to a really controversial conclusion with zero data to back it up.

This is a good hypothesis as it stands, and may be valuable as a predictor of fraud. However the conclusion is meaningless without sufficient evidence of predictivity to back it up.

Take historical examples of elections with known fraud and run this analysis to see if it can correctly label the fraud/no-fraud categories. _Then_ after we can agree that it works well, only then will I care about the results of any specific analysis.

Without historical context this analysis is meaningless. Is this one election the exception or the norm?

Remote work is like an iceberg with most of the work force being located in ad-hoc remote positions. Many companies have remote employees, but don't actively hire people into it. There are some companies that have built their entire culture around remote work, like for example github, but those companies are still uncommon.

$200 is definitely viable to find a laptop, check Amazon for example. The question now is what development environment do you want? Windows, Mac, or Linux?

I don't hold corporate bonds. That seems really easy to screw up if you don't know what you are doing. I think it is a reasonable option for financial professionals to choose if they are looking for slightly higher returns and are willing to invest the time to do due diligence, but for everyday investors I agree definitely stay away before you lose your whole investment.

As a project ages more thought shifts from development to maintenance and external concerns. What is good for a young project is usually not a good fit for a mature project. Specifically, young projects tend to care more about automated documentation generated from code, whereas mature projects just want a good content management system.

If it is still running, then it at least has operational staff responsible.

linux + bash + ssh + nano. not necessarily in that order. puts me on any server environment with a swiss army spaceship in hand.

Google has a lot of data but proportionally fewer people. If you pursue your venture, you can put more attention to specific areas than Google will ever care to do. Find a niche and start digging a trench.