• 0 Posts
  • 41 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle


  • It definitely gets easier in my experience. A lot of the things that take conscious effort right now are going to become reflexes and automatisms with more experience. Right now you are building that experience, and there isn’t really a way to speed it up. You just need to do each action dozens and hundreds of times, until you do it without thinking.

    Driving a manual car, for example, is definitely more complex than an automatic one. You literally need to manage one more thing. But do not worry about it, you will change gears a lot during your practice sessions and build a lot of experience quickly. In a few months you will probably not think much about gears, and in a few years you will be managing them without giving it a single thought.

    Fun anecdote, I recently got a new car and it is an automatic one while I previously only drove manuals. For a few days I couldn’t figure out how to start smoothly, and I was very confused… until I realized that starting mostly involved the clutch on my previous car. The first movements of my right foot used to be to keep the rpm under control while disengaging the clutch, which is just not needed on an automatic car. I was simply applying the same muscle memory to the new car without realizing it!







  • If the timestamps line up, maybe Wireshark just doesn’t manage to understand the entire exchange. What could happen is that Wireshark sees the SSH handshake, and after that it might become just encrypted gibberish due to the encryption. In that case the SSH traffic could just show up as “some kind of TCP”.

    Do you see an SSH handshake, followed by random crap on the same ports?

    (I’m not a Wireshark expert, just an IT guy trying to help!)











  • That is true, but from a human perspective it can still seem non-deterministic! The behaviour of the program as a whole will be deterministic, if all inputs are always the same, in the same order, and without multithreading. On the other hand, a specific function call that is executed multiple times with the same input may occasionally give a different result.

    Most programs also have input that changes between executions. Hence you may get the same input record, but at a different place in the execution. Thus you can get a different result for the same record as well.


  • That exact version will end up making “true” false any time it appears on a line number that is divisible by 10.

    During the compilation, “true” would be replaced by that statement and within the statement, “__LINE__” would be replaced by the line number of the current line. So at runtime, you end up witb the line number modulo 10 (%10). In C, something is true if its value is not 0. So for e.g., lines 4, 17, 116, 39, it ends up being true. For line numbers that can be divided by 10, the result is zero, and thus false.

    In reality the compiler would optimise that modulo operation away and pre-calculate the result during compilation.

    The original version constantly behaves differently at runtime, this version would always give the same result… Unless you change any line and recompile.

    The original version is also super likely to be actually true. This version would be false very often. You could reduce the likelihood by increasing the 10, but you can’t make it too high or it will never be triggered.

    One downside compared to the original version is that the value of “true” can be 10 different things (anything between 0 and 9), so you would get a lot more weird behaviour since “1 == true” would not always be true.

    A slightly more consistent version would be

    ((__LINE__ % 10) > 0)