The title is pretty shitty but you should at least click through before making a comment.
This is a contribution to Coreboot, which is an alternative to UEFI/BIOS.
As much as I dislike US government agencies in general, I think this time they have good motive to provide good code. Undermining this code would also undermine the systems of other government agencies.
In this case, I trust the NSA more than random contributors on the internet that have less known motives and may in many cases be agents of foreign spy agencies.
>The title is pretty shitty but you should at least click through before making a comment.
Something, something, site guidelines about suggesting the commentor didn't RTFA.
>I trust the NSA more than random contributors on the internet that have less known motives and may in many cases be agents of foreign spy agencies.
To be fair, I think that you stated the OC's point and failed to recognise it:
Your domestic spy agency is another's foregin spy agency. Why should they trust yours over theirs? Both have (presumably) equally less-known motives, yeah?
I'm not sure what it is about this video I don't like. It just didn't seem very much like a 3B1B video for some reason. Maybe it's because there were fewer "A HA" moments than in other videos. Maybe its the source material. Just feels...different.
Not sure why you did not have any "Aha" moment, bu the visual explanation used for the principle of superposition and approximation of functions by Fourier series is very informative. I also liked the explanation about the proportional relation between temperature and space in the heat equation. I think in most higher educational systems, they only approach this type of problems with pure theoretical solutions/explanations.
At the default setting, there is a noticeable absence of ships in the Atlantic to the west of the British isles - where is the traffic between Northern Europe and the Americas? I wondered if it was due to really bad weather (no - it appears to be good), but if you zoom in, the traffic appears.
As far as I can tell, this is not a consequence of the filter settings - no exclusions seem to be set.
Within AWS, consider DynamoDB with the fantastic DynamoDB Lock Client[1]. It’s a “general purpose distributed locking library built on top of DynamoDB. It supports both coarse-grained and fine-grained locking.”
interested to know your approach to long leases lasting more than 60 seconds (if you have this?). do you go for continual renewing (and bailing out if you get too close to the timeout without getting a renewal). or do you go for infinite with your own break logic?
Time is hard.
But like what does it even mean to say something is 4 months away when the months could be different lengths? 4 months is a shorter time if that period includes the end of February. This fixed result is strange but does it even matter?
what does it even mean to say something is 4 months away when the months could be different lengths?
The same thing it means when something is 2 years away when the years could be different lengths?
The month is a well-defined unit within the context of a certain calendar. And since a normal date representation contains the month as a singular component, month additions are usually well-defined (the obvious exception being, adding N months to yyyy-mm-31 -- the result is undefined, though most people will assume it to refer to the first day of the month following).
There is no need to bring mathematical strictness into it, because months are never used for that purpose. Moreover, no calendar system is built for mathematical strictness anyway, so arguing for that kind of strictness is like building a house on quicksand.
> though most people will assume it to refer to the first day of the month following
I wouldn't, I'd assume it's the last day. For me, any date that is "two months after" any date in July should fall in September, with the days longer than the target month scaling down. So two months after July 31 should be, to me, September 30.
But,
$ date -d "2019-07-31 +2 months"
Tue, Oct 1, 2019 12:00:00 AM
> (date 2019-07-31).AddMonths(2)
Montag, 30. September 2019 00:00:00
.NET agrees, though :)
For software libraries it's a bit of a pickle, though, as you have the trade-off between »do what an end user would expect« and »do exactly as told, and let the programmer deal with the weirdness«. Admittedly, adding months is something that I'd rarely do as a programmer when the context isn't what a user would expect. Adding 30 days can be done in much the same way if that's really what's intended.
Interesting question, though: Is 2 months from 2019-07-28 2019-09-28 because the day part is the same, or 2019-09-27 because it's three days from the end of the month? ;-)
You're right, but I think the problem does arise for "four and a half months away". That actually requires you to pin down how many days are in a month.
There is -- or should be -- an understanding that when such a phrase is used, it is not intended to be taken as a precise duration. Furthermore, for any of these expressions, while there is not necessarily just one moment in time that it is equivalent to, there is a vast range of times that it definitely does not denote.
It only requires you to know how many days are in each month, and you have to know what you’re counting. That’s the problem with calc: it discards the semantics of “how I got here,”
I think it's more complicated, and depends on assumptions made by the speaker and the listener: if I say "two and a half months from now", is the half-month equal to 15 days or 14? If the target duration is February, perhaps I'd assume 14; but otherwise I probably assume 15; but what if February is one of the whole months in between?
In my experience (in my culture), we avoid these problems by just assuming that we'd never convey a precise date in this manner: anything more than a week away we tend to convey with the exact date (March 15th); or, we might say "exactly two weeks from today" or "exactly one month ago" (implying the same numerical day-of-month, regardless of how long each month is), but I don't think we'd ever say "exactly one and a half months from now".
And this is why calendars are hard: it's as much (or more) anthropology as it is arithmetic.
True, but you wouldn't use that in a context where precision is required. You'd say something like '31 weeks' if the specific duration mattered, or just the date itself. When the exact duration isn't particularly relevant, the ambiguous 'four and a half months' works just fine.
One of my first gigs we did a LOT of work with a Sybase database. Backend code frequently made calls to the Sybase database for no reason other than to use the DATEADD and DATEDIFF functions because they were so reliable and easy to use (except for being in a database).
Dates are actually always durations. But most time libraries design fail to aknowledge that. When you say something is 4 months away, it means you're probably happy with a 1 month resolution. 4 months from 31 July is November. 4 months from any day in July is always November.
