And according to them, valgrind (and linux) can be qualified as beautiful piece of code[1]:
"Valgrind is perhaps the most amazing and useful developer tool in the world. Valgrind is a simulator - it simulates an x86 running a Linux binary. (Ports of Valgrind for platforms other than Linux are in development, but as of this writing, Valgrind only works reliably on Linux, which in the opinion of the SQLite developers means that Linux should be the preferred platform for all software development.) As Valgrind runs a Linux binary, it looks for all kinds of interesting errors such as array overruns, reading from uninitialized memory, stack overflows, memory leaks, and so forth. Valgrind finds problems that can easily slip through all of the other tests run against SQLite. And, when Valgrind does find an error, it can dump the developer directly into a symbolic debugger at the exact point where the error occur, to facilitate a quick fix."
[1] https://www.sqlite.org/testing.html
I was reading [1], and was lectured on how the sun can be used as telescope and a very potent one, btw. Picture at [2]. Searching, I found the linked article. Quote:
"I anticipate that there will be a host of FOCAL space missions launched in all directions around the Sun, each probe launched in the direction exactly opposite to the star to explore with respect to the Sun position…. A FOCAL space mission could be used to magnify anything of interest outside the Solar System. One should then say that FOCAL will be used to magnify the nearby planetary systems, meaning not just the nearby stars themselves, but also their planets, halo disks, Oort clouds, etc."
According to some comments in the article (specially andy's, very informative), one could see another stars' Mercury! Very impressive. And since all EM range is focused, one can use the focal point for radio communication, ala NASA space network[3].
Some catches though: we need to send a probe to 550AU. That would take almost 200 years. Talk about planning ahead :).
From the article:
"...a black box monitoring of the system is not sufficient. Black box monitoring, including external monitors, canaries, and so on, only tell the system which side of an externally visible failure boundary a system is on. Many kinds of systems, including nearly every kind that includes some redundancy, can move towards this boundary through multiple failures without crossing it. Black-box monitoring misses these internal state transitions. Catching them can significantly improve the actual, real-world, durability and availability of a system."
The author uses RAID, but this observation is valid for systems in general.I really wished that was some kind of guidance, manual or best practices available on how to design and/or auto-regulate those internal state transitions.
It seems like there's a possibility for a general rule-of-thumb (that could be operationalized) in systems that try to use redundancy to increase fault-tolerance.
The naive approach would be linear: treat two half-failed drives in a mirror as having one whole failed drive. That wouldn't work too well, though mostly because "half-failed" is actually nearly already failed.
This seems like the kind of thing that could use a "calibration curve"—where you observe how the reported health actually correlates to the remaining MBTF, and then divide future reported-health estimates by that correlation-curve to get their actual health.
I'm guessing the calibration curve will just, itself, end up being a bathtub curve—which means that e.g. a drive with one or two SMART errors would need to be considered "already on its way out." But sometimes such drives live a long time—as a matter of cost, it's probably too expensive to throw out every disk that will probabilistically fail soon. It might be possible, though, to move them to some sort of "non-front-line" service instead, maybe moved to Dynamo-like n=17 highly-redundant storage. (I wonder if AWS actually "recycles" EBS volumes into Dynamo/S3 volumes this way.)
---
As an aside, I've always wondered why we don't use calibration curves more. They're great for estimating a lot of things:
• Remaining battery life: sort of works this way (in that battery output is fairly constant until the battery "runs out"; 10% remaining = battery at a slightly lower voltage, 0% remaining = battery still plenty charged but no longer charged enough to output the proper voltage for the device.) But could be calibrated way better by actually correlating reported battery life to time, as observed by the device during its service life. This is made harder because we don't usually let batteries drain dry, though we do let them get into that precarious 10% "suboptimal voltage" case quite often. A properly-calibrated battery report should discharge linearly and recharge on an S-curve, rather than the other way 'round.
• Progress bars. If you're an OS manufacturer and you want to distribute an OS update, deploy it to a bunch of test machines and track how long each phase of the update takes, average them a bit pessimistically (maybe take the third-sigma median.) Now you can make a progress bar that appears to fill linearly, and gives a real, calibrated estimate on time-to-completion. The bar can be fronting pretty oblivious software, as long as it's split into phases itself: each phase can be kicked off and then the bar can just ease between N% and (N+P)% over the (pessimistically) estimated phase time, quickly cubic-sliding up to (N+P)% if the phase completes early. (I do know one piece of software that actually did things this way: Mac OS, pre-System-7.)
Not sure if you are joking but I use bookmarks as my preferred read-later tool.
Firefox helps a lot with sync, open all in tabs, bookmark all and click/drag to reorder links.
I just put the link in "atHome" folder so to read it with more attention at,you guessed, home.
The folder "atWork" is reserved for links where I must run some code, test some new library, etc due to more powerful machine.
I have another folder "daily", for sites I visit every day (hn, soylentNews, hackaday, etc) and long posts eg with chapters (books, for instance);
The folder "Weekly", for low volume sites, basically comics.
This, together with some speed reading, BS skipping and troll detect works very well, to the point Im often run out of things to read.
I always felt Firefox's Unsorted Bookmarks was a great inbox for articles to read later or ones you're not sure whether to read yet. I'm kind of surprised that concept hasn't made it Chrome or Safari. Likewise with bookmark tagging.
Interesting, this is the kind of feedback I was looking for, thanks.
I did try bookmarks quite a while ago (IIRC, in Firefox), including a few of the things you mention. I think I found it had some limitations. But that was a while ago. Maybe I didn't try enough variations or tweaking of it. Will check it out again.
I liked how he challenged our edge-detection NN in lesson 3. With a gray paper, it is possible to use a dark and white pencils, making 2D looks like 3D.
He does it again in lesson 8, drawing some leaves.
"A black man with an IQ of 85 and a white man with an IQ of 85
are about equally likely to have the character traits of poor impulse
control and violent behavior associated with criminality — and
both are far more likely to have them than a white or black man with
an IQ of 110" -Eric S Raymond
"Valgrind is perhaps the most amazing and useful developer tool in the world. Valgrind is a simulator - it simulates an x86 running a Linux binary. (Ports of Valgrind for platforms other than Linux are in development, but as of this writing, Valgrind only works reliably on Linux, which in the opinion of the SQLite developers means that Linux should be the preferred platform for all software development.) As Valgrind runs a Linux binary, it looks for all kinds of interesting errors such as array overruns, reading from uninitialized memory, stack overflows, memory leaks, and so forth. Valgrind finds problems that can easily slip through all of the other tests run against SQLite. And, when Valgrind does find an error, it can dump the developer directly into a symbolic debugger at the exact point where the error occur, to facilitate a quick fix." [1] https://www.sqlite.org/testing.html