As an Italian I am failing to see the cleverness, even if they are written the same wind and wind (different pronounciation) have different roots and meanings.
Can't recommend this highly enough, if for no other reason than to provide some context to help the OP from getting trapped in the "deep learning is all you need" echo-chamber. Sure ANN's and DL are great and do amazing things, but until it's proven that they really are the "be all, end all" (something I suspect we're far from) then it makes sense to dedicate at least some cycles to considering other paradigms.
Everybody is talking about the need to incorporate knowledge representation and reasoning into the statistical models in vogue currently. Russell&Norvig will forever be relevant. Those guys are at the forefront of research in the academy and industry respectively. They have a mature perspective.
yeah, which is why I have “write once, run anywhere” in quotes. The difference being that this is language agnostic and run by standards bodies. its just a compilation target.
We already are trying to do write once, run anywhere with containerization, except that containers use lots of memory and space because you need to virtualize an entire OS.
Whereas WASM is just the bytecode for my program, and I can give that to a WASM interpreter or a compiler to compile to machine code.
I think OP's case was not debugging a crash, just that if a crash happens he would like the log to be before rather than after. The log statements would be there no matter whether there is a crash or not, just in case.
Despite some (already mentioned) shortcomings, I like it: it provides a simplified "real life" big picture of the whole process with sample tools; a thing that (in my experience) every other "getting started" guide seems to miss (most of them just mentions what is a makefile).
I also like the overall format of the website and the radio feature is a nice touch. I'll visit it again in the future, out of curiosity.
A follow-up article may extend it with collaboration (git) or may delve in either Unix-like (e.g. with the GNU utils etc) or Windows, or both. But the author should first address the highlighted shortcomings...
I'm using Postgres FDW at my current work and, while it has its advantages and use cases, JOIN operations can be terribly slow. Also, good luck (not) working with remote sequences.
I’ve implemented a (relatively simple) FDW myself. Performance largely depends on the operations you can push down to the native store. In some cases (e.g. SQLite and remote Postgres) that includes not just selections but even joins.
There's some query planner tweaks you can use to speed up JOINs with FDWs [0]. In layered querying [1], we had an issue with the planner choosing nested loop joins (which essentially run as multiple small single-row fetches) which tank performance if starting a scan has a large latency overhead. This can happen if the FDW underreports its startup cost.
If you use `SET enable_nestloop=off`, this will disable them for that session and use alternative strategies (like hash or merge join) which might be faster.
Common things are simply by category and subcategories starting from the media/file "type" (e.g. books, photos, etc).
Projects are created in a ~/playground directory and are eventually moved to a ~/projects one (but sometimes they just stay in a RAM-disk; i.e. experiments).
Within coding projects I usually have /src, /doc (by category and subcategories) and /utils (with utility scripts, Docker-related files, etc) sub-directories.
PDF et similia that don't fit within a specific project typically are generic enough to be placed somewhere under ~/books.
The main issue with this system is that there could be work-related things under distinct paths (e.g. ~/documents/work/<org> and ~/projects/<name>), but those may be archived together...
