That first article seems to assume that you know both the start and destination positions of the entity, but usually you would only know the starting position, as the player will already have moved past the most recent position received from the server.
For a networking engine I've been working on I'm predicting ahead using linear interpolation to get an estimate for where the player will be, and then using the information received from the server to calculate a correction value, so if I receive an update from the server which was the position 100ms ago, I look at where I had predicted the entity would be at that time and find the difference.
This correction is then applied to the current predicted value over a certain length of time so that the predicted position smoothly adjusts to the actual position.
I also don't bother with the back-in-time hit detection described in the source multiplayer article, since the clients don't lag behind the server as much in my model, and in reality bullets do take a few milliseconds to travel, so it doesn't matter if there is a small delay between the client sending the fire message and the server acting on it.
[b]
