fburnaby

I do not think this extra justification is necessary, but it is valid.

This distinction is a more useful one that the article made. I love dockerfiles and immutability, but there are good cases for mutable containers, too.

it's like a very small part of a thesaurus.

Does anyone here know if and how the IHO's S-100 data formats relate to this?

I can't see from the docs what this gives me over a Makefile, Asciidoctor (or pandoc, Jekyll etc), and D3?

does that apply to installations from apt?

This also happens to me in Chrome on Pixel 4a.

asciidoc is my favourite too, thanks to Asciidoctor. I agree, asciidoc hits the sweet spots as a format. Been frustrated by the tooling lately though. I can see the huge effort put into Asciidoctor, and am thankful for it, but there are still big downsides i.e. no semantic html 5 output, difficult (or at least more difficult than necessary) integration with image generators, heavyweight (only ruby dependency on my entire machine). I imagine this just needs more time and resources put to it, as all these issues (except the ruby one) are open on GitHub.

I have no expertise, but this is my sleep. It turns out I have sleep apnea. I can "sleep" for 8 hours, but it does very little good. With apnea, you wake up as much as a few times an hour, getting very little REM. It took me years to consider apnea because I'm thin and somewhat fit. But all sorts can have it.

Philosophy of Science by Jeffrey Kasser

I have to disagree with other responses. I think you could make a career of this for the same reason management consultants can.

You could swoop in and "fix" some stuff and then leave the in-house team not understanding what you've done. That sounds profitable. You might even get called back to fix things a second time.

As with management consulting, I think it would at the system level tend to do more harm than good, even if you do good work and get paid well for it. I agree strongly with feoren that the code needs to reflect the in-house developers' mental models of the domain or everything will fall apart. If you fix things and then give them a bunch of processes and coding standards to follow, they will not do well and you will be thought of as some clueless architecture astronaut by them. But profitably.

I have been getting tired of node dependencies and not knowing what I'm running or when it will break. I make simple things for small number of users and started playing with just writing my own CGI in C++ or bash behind thttpd. This appears to be working very well so far and runs on a vanilla Linux install with deps just on system libs and gcc. With all the pain and unsafety of deps, this might actually make most sense. What new vulnerabilities am I inviting? Why aren't we still doing things this way? It seems... much easier, perhaps not to make it but to secure and sustain it.

I find this pervasive idea that "documenting" things is just a thoughtless dump of facts very troublesome.

Certainly, most "documentation" I read is just a thoughtless dunp of arbitrary facts about some system, design, code, or event or what have you. But it should be better.

There are infinitely many true statements to make about some thing in order to document it. The art is in determining which ideas and facts about it are relevant for an audience, and finding a way to express those ideas and/or facts clearly for.that audience, in a logical order, using good prose, diagrams, etc. I think that's as hard as any other writing task, and arguably more valuable than many. Documentation captures facts for record and makes them accessible to some audience who otherwise would not have known about that thing. What could be a more important kind of knowledge work than that?

I agree with all of this. Submodules aren't easy but they perform a useful job. It's hard to see how they could be made significantly easier. Where else in software is dependency management easy and convenient?