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. :)
HN user
dezzeus
You may want to also consider this one:
Artificial Intelligence, a modern approach – Stuart Russell, Peter Norvig
This video of the UNIX OS: https://youtu.be/tc4ROCJYbm0
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.
Among the free ones there’s https://drawpile.net/ but I haven’t tried it yet…
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...
For the readers, I'll add a gently remainder that this is about Canada whose southern border is located at about 50°N. That means that the shift in daylight that they experience during the year is quite amplified.
Beside that, the article is quite poorly written and misleading! Do not assume that everything said apply for the rest of the world.
Changing our clocks twice a year has little benefit, economic or otherwise, so isn’t it time to stop this antiquated practice?
Yeah, thanks for such a scientific sentence with no explanations, no data, not even an introduction to the topic. Next time maybe also ask some astronomers…
As experts on biological rhythms, we support the switch to a permanent time.
That's perfectly fine, but at least explain why… and provide advice for the current practice (e.g. for the Spring change, move up your daily routine/schedule by 3 minutes every day for the 20 days before the change, so it will occur smoothly).
People on the western edge are forced to get up an hour earlier than people on the east, according to sun time.
What ?! Not in standard time-zones. That can happen only in countries which span across different time zones and decides to keep a single "official" time.
Analysis of health data from millions of people shows that […]
No source at all; that seems more a supposition from a USA article. They see sunrise/sunset 19 minutes early (depends on the latitude), but that doesn't mean that they sleep less. All the rest is just bullshit.
Permanent DST would make sunrise even later for everyone, while permanent ST would make sunrise closer to body time.
In the northern emisphere permanent DST would make sunrise later in the Winter; permanent ST would keep the sunrise to the current optimum (for the Winter; during the Summer we already wake up with the Sun).
I'm a big supporter of 2D-defined time-zones, but not for what your're saying.
The overall debate revolve around daylight which change in function of one's latitude.
With an internationally agreed grid (e.g. current longitude division plus steps of 15° of latitude), we may solve those problems easily for everyone, wherever they lives.
Maybe because its latitude is within the ±30° range from the Equator, hence the no need for DST ?!
Please, Standard Time is preferred globally, but don't confuse the topics.
I'm going to write a couple of things about the first point.
Several years ago, a knowledgable guy told me that the most compelling reason for choosing between PostgreSQL and MySQL was the expected I/O: "for read-intensive workloads (e.g. blogs), choose MySQL; for mixed workloads (e.g. forums), choose PostgreSQL".
But I honestly don't know if that may still be valid as of today.
Nowadays, I think that for basic things, it doesn't really matter; but for peculiar things, Postgres may have some advantages (both technically and not). Also keep in mind that, for some popular scopes, SQLite is likely everything you really need.
* Winds are driven by the pressure difference (from high to low).
IMHO enforcing public groups is probably just a way to collect data from user’s public activity, which allows for better targeted advertising without boring (themself) with privacy. Which is fine if used in a good way.
Yes, because DST correctly attempt to adjusts Sunrise towards our usual wake-up time (obviously it can't do miracles).
When you describe it this way
Which is by far one of the most accurate description in this community.
the entire process sounds like something that takes place in a totalitarian state run by a crazy person
It's due to the way the Universe works, it only requires a review of your early school notes about science / geography / astronomy.
DST is a way to compensate that "strange" behavior for the current definition of a "time-zone".
Is DST good ? it depends because we over-generalize the definition of a "time-zone" by taking in consideration only the longitude, but not the latitude. (and above/below certain latitudes, nothing can be done)
Is DST good for EU (or North America) ? Mostly yes if you take a closer look at the year-round daylight charts for key geographic coordinates.
Extra notes while here:
1) "EU propose to get rid of DST", its our best interest to keep it; don't let some incompetent rule such a thing because he/she doesn't really know how it works but only how it's perceived.
2) "If I have to choose, I prefer more daylight in the evening": fine, but that is out of scope from DST; it's about changing schedules. Clock should (I'd say "must") stay on their natural "time-zone" for the sake of coordination and travel.
You're both right and wrong: the need to "move" that hour is needed only during a period of the year (latitute-dependent; on average March-October in the northern hemisphere) that mostly cover the Summer (Winter in the southern hemisphere), in order to synchronize our body-clock with the sunrise (which depends on your location).
Obviously a solution that is "one size, fit all" doesn't exists, hence those (poorly informed) discussions...
The energy's story is mostly a consequence.
It's called Daylight Saving Time (DST), not Electricity Saving Time (EST ?!). While some of the thoughts around it seems to have started with energy consumption (and thus cost) in mind (which proved useful in time of war), those were just consequences with little to no reason nowadays. The reasons are astronomical and therefore DST must be somewhat observed; it's the implementation approach that must be improved (IMHO together with the time-zones implementation), but people doesn't seems to understand it.
I basically do the same with my beard within the chin… I usually pick those "not perfect" and also those who are grown slightly longer than their neighbors…
Me too with Opera (Beta 54) on MacOS (10.13) :/
We are used to consider time-zones due to the useful subdivision of the Longitude in 24 steps and with that we all (should) agree.
The disagree generally comes when we talk about DST based on our main location (and thus experience), but the problem is intrinsic in the elliptic, so it must be addressed from another point of view (IMO): the Latitude.
I think that we should consider a further subdivision of the coordinate space; not only Longitude by 24, but also Latitude by something reasonable (e.g. every ±30° from the Equator; maybe not even of equal size but based on regions of the climate system).
With "time", we may acquaintance with this new kind of grid-based time-zones (which are easy to memorize/map-to given a basic knowledge of the Earth).
Any (useful) opinion ? :)
What exactly is the benefit of using sqlite over mysql in this case?
I'll just let you read this: https://www.sqlite.org/whentouse.html