dezzeus

I'd like to highlight the wordplay around re-wind: Vento means wind (as moving air) in Italian, and ventoso (vento.so) translates to windy. :)

You may want to also consider this one:

Artificial Intelligence, a modern approach – Stuart Russell, Peter Norvig

I don’t want to be harsh, but to me it sounds pretty much like the value proposition of the JRE (Java Runtime Environment) et similia…

Even though it can be lost by an optimistic configuration, I prefer to use the TRACE level(s) and leave the DEBUG one for, well, debugging.

I was curious, but Safari is reported to not be supported for anything, neither for see a homepage.

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 actually interested… (I'm quite limited to Apple's bundles) would you mind writing a blog post ? :)

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.

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...

IIRC you should strive to never reach the extremes; i.e. keep in the 20–80% range in order to maximize its lifespan.

Another tip was to avoid rapid energy consumption (such as from intensive use of CPU or discrete GPU usage) while on battery.

My main issue is that whenever you plug an external monitor, this automatically trigger the discrete GPU, and I'm using an external monitor for working from home (due to the cervical), so I'm mostly using the charger.

Of course I have, but that's not exactly what I was aiming for... ;)

I expect it to be a little better trade-off given the following points:

1. JS is kept for what it's meant to be and do; nothing more.

2. A WebKit webview is probably lighter than Chromium + NodeJS.

3. The whole thing should be managed to be linked as a shared library, avoiding many pitfalls of Electron's applications (by means of a semantic-versioned library).

4. The whole solution is really language-agnostic, despite my efforts with Go.

I've just started designing something very similar in my free time, but for Go (golang): interface around native GUI + WebKit webview + React + bindings.

I'm glad that we are slipping away from Electron...