diekhans

It seems like a bug report on what is not clear in the documentation would be highly useful.

No API to hook into one's favorite tools, such as emacs.

https://www.norvig.com/21-days.html

This is likely true for many companies. However, it is also a metric for what type of working environment it will be. I value being able to learn quickly and creativity over pre-training.

The article doesn't understand programmers. People will stay because they are passionate about OCaml and there are not a lot of OCaml jobs.

When hiring for a permanent position, I have the expectation that a programmer can learn a new language and environment. An OCaml programmer for a position that is python or C would be looked on very favorably. Far more attention-getting than “full-stack programmer”.

Plus the 64-bit integer problem, really 52-bit integers, due to JS not having integers.

Nicely written (and executed). Worse that my worst memory corruption.

Hard rules are the problem. There is a lot of "it depends."

After over 40 years of programming, I continue to reduce the size of functions and find it easier to write and understand when I return to them. Ten lines are now a personal guideline.

However, a linear function with only tiny loops or conditionals can be easily understood when hundreds of lines are long, but not so much with nested conditionals and loops, where there is natural decomposition into functions.

I observed that the same guidelines became rules problems when test coverage became popular. They soon became metrics rather than tools to think about code and tests. People became reluctant to add sanity check code for things that could should never happen because it brought down code coverage.

I have had good luck with duplicacy for cloud backup: https://duplicacy.com/

Circos is useful when the data is sparse and quickly becomes extremely time-consuming to near-impossible to interpret. The most you can say is "wow, there is a lot going on".

I know in five seconds if a Circos plot is worth looking at.

This is awesome!!

Thanks for the reply.

I try to use exception chaining to create a message that is useful for the user to actually debug the problem (solution-directed error message).

The classic toy case is either getting back "permission denied" or "can not open foo" but not both. Chaining of error messages gives a straightforward mechanism for this.

Then, the high-level text, along with the caused-by messages, is displayed without a stack trace to hopefully give the user enough information to address an issue.

Chaining can be done with explicitly returned errors as well as exceptions. The hard part is actually thinking about "is this use to the end user"

The point of chaining exceptions is to add information to an error result. It prevents one from having to pass down information to produce an error message that makes sense to the user.

No data checksumming is one of the main reasons not to trust APFS for valuable data. Maybe it is fine on Apple SSDs, but what about terabytes of data on external disks?

Why checksum metadata if the SSD is so safe?

It's an interesting package, and I have some of the use cases it appears to address. However, the documentation is inadequate to quickly understand how to robustly build some of the more complex cases. In particular, how to build bash-style process substitution. Robust here is the pipeline exits non-zero if any of the substituted processes fail, as demonstrated by this example:

    #!/bin/bash
    set -beEu -o pipefail
    cat <(date) <(false)
    echo did not exit non-zero

I have been having great luck with incremental backups with the very similar named Duplicacy https://duplicacy.com/

My view is that automated testing is not a substitute for QA, but an additional tool. It lets QA focus on harder to automated tasks.

For unit tests, a developer is going to try something out anyway, so capturing it in a unit test for the future should be just a little extra work. Also, writing a unit test means the developer has minimally used what they are writing.

Higher-level (system) testing, especially with GUIs, can be more work than the value added. It is a cost trade-off, but ultimately, a human adds value not matter how much automated.

AI will help too, but these are also tools. Drop QA and you are trading off costs for quality.

IMHO, not backed up by research.

Darktable is an interesting project and an impressive effort. However, serious photographers tend to use Lightroom. It is just eons beyond Darktable.

Sometimes even those of us who love programing want to use software rather than develop it.

Setting backup-directory-alist to ((".*" . ".emacs.bak")) keeps the files local to the actually files, without the cognitive overload of being adjacent to the edited files.

We really should say "a human genome". Reference genomes serve as a Rosetta Stone of genomics. So we can take DNA/RNA sequences from other individuals and align (pattern match) them to the reference as a way of understanding and comparing individuals.

It is not perfect, as a references can be missing or have large variability in DNA regions. The goal of the Human Pangenome Reference Consortium (HPRC) https://humanpangenome.org/ is to sequence individuals from different populations to address this issue. We are also working to develop new computation models to support analysis of data across populations.

After years of BSD and Linux on my desktop, I finally figured out that the desktop is about applications. Many of us need to actually accomplish things in addition to develop Open Source software.

Had M$ been broken up, maybe it would be different. Until things change, I am happy that at least I can run applications on UNIX based MacOS.

3% is just sarcasm

It is amazing how much time projects seem to spend on rewriting history for the goal of displaying in in a pretty way. Leaving history intact and having better ways to display it seems far saner. Even after a merge, history in the branch maybe useful for bisect, etc.

Lot of good info and saved away!

However, it drinks the code coverage cool-aid that started like 30 years ago when code coverage tools emerged.

Management types said "high test code coverage == high quality"; lets bean count that!!

A great way to achieve high code coverage is to have less than robust code that does not check for crazy error cases that are really hard to reproduce in test cases.

Code coverage is a tool to help engineers write good tests. One takes the time to look at the results and improve the test. It is a poor investment to be obsessed with code cover on paths where the cost to test them greatly exceeds the value.

10% coverage and 100% are both alarm bells. Don't assume naive, easy to produce metrics are the same as quality code.

Otherwise, and excellent article.

Not used ECC is not a good tradeoff in my experience. The only ZFS corruption I have experienced was direct attached ZFS on a Mac with memory errors undetected by Apple's diagnostics.

Has this been reported to apple? One would think they would pay attention to something that makes the M1 look slow it it reaches the right people.

I18N was one of the few things POSIX didn't do well. Have an environment variable change the sort command causes lots grief.

I stand corrected, I had "Practical Extraction and Report Language" wired into my brain when I fist used in version 1.*.

Disliked is horrible syntactic and semantic complexity then as I do now.

However, that didn't stop people from doing great things with it.

Now, I have to find a bug in someone's Perl program

PERL (not Perl) has been almost completely displace in genomics by Python.

IMO, it is an inane language with amazing regular expressions.

It was C, Jim Kent hates C++

Ceph is supported on FreeBSD

https://www.freshports.org/net/ceph14/

All I can say is THANK YOU!!! I use mosh 10+ hours a day. Maybe it needs a bit of help, but it is in my top 10 of "how did I accomplish anything with out mosh.