MQTT

To get a feel for how much pseudo-random data is available in your entropy pool, you can run this command:$ cat /proc/sys/kernel/random/entropy_avail 2684 The number shown appears to represent the number of bits of entropy that have been collected. Even 2,684 might not seem like much in a world in which we routinely speak in terms of terrabytes, but numbers above 100 are said to be a good sign. I

I'd like to offer my thoughts on ctime verses mtime. Sorry, but this will be a little verbose. First, if you change the contents of a file you change the mtime of a file. Since this is a change to the inode, ctime is updated as well. The mtime is bit like the date on a letter and ctime is a bit like the postmark on the envelope. You can set mtime to anything you want via the utime() system call or the touch command. Doing so sets the ctime and you cannot reset ctime. If you restored last year's payroll records from tape, you might want to set the mtime back to the end of last year. But the ctime will reliably still indicate when the last change to the file occurred. This is how your backup program will know that it must back up the file. The ctime is really used by backup program. But an application program that prints out a payroll listing would use mtime.

ctime indicates inode data change: ie. when you do chmod. chown on the file or when the file size changes. Not the contents of the file.

ctime refers to changes made to the file's inode (such as changing permissions, etc). mtime refers to changes to the data within the file. So cnewer will use a reference files inode change time for the comparision, whereas newer will use a reference files data modification time.

And that’s it, look by yourself what happen if we uncompressed the commit file : // by looking at the history you can easily find your commit hash // you also don't have to paste the whole hash, only enough // characters to make the hash unique git cat-file -p 4cf44f1e3fe4fb7f8aa42138c324f63f5ac85828