But maybe that's more a measure of my own age and perceptions rather than an accurate representation of the various eras of the internet/web...
1,925 karma · joined November 24, 2008
I sometimes say intelligent things on Mastodon: https://hachyderm.io/@malware
I write about things that interest me at https://nerderati.com
[ my public key: https://keybase.io/jperras; my proof: https://keybase.io/jperras/sigs/MiFx-5FlZM7UAxXxqEUihKkwRawBofkeg7q7wD4NmfE ]
But maybe that's more a measure of my own age and perceptions rather than an accurate representation of the various eras of the internet/web...
Agreed. I have a Pavoni Europiccola, and it's made approximately ~11,000 espresso shots (about half of those ended up as milk-based beverages). It makes excellent coffee, and I live in a place where there are a _lot_ of good coffee places around to compare to.
The maintenance is something I do myself, with a few small & inexpensive tools, and a few gaskets I need to replace. The machine will likely outlive me, which is a rare thing to say these days.
The cutoff used to be early 2008, I believe, but that may have changed in the last ~17 years :)
The BMW turbocharged M12/M13 that was used in the mid-eighties put out about 1,400 horsepower at 60 PSI of boost pressure, but it may have been even more than that because there was no dyno at the time capable of testing it.
They would literally weld the wastegate shut for qualifying, and it would last for about 2-3 laps: outlap, possibly warmup lap, qualifying time lap, inlap.
After which the engine was basically unusable, and so they'd put in a new one for the race.
As one comment pointed out, they could be using nitrocellulose in the handle.
OP: I may or may not be in possession of hasitlaunched dot com, should you be interested in purchasing it…
That's what you should be using exponential backoff for. In actuality, the new latency introduced by the backoff should be maintained for some time even after a successful request has been received, and gradually over time the interval reduced.
> I much prefer setting a fixed time period to wait between retries (would you call that linear backoff? no backoff?)
I've heard it referred to as truncated exponential backoff.
This place has both changed a _lot_ and also very little, depending on which axis you want to analyze. One thing that has been pretty consistent, however, is the rather minimal amount of trolls/bots. There are some surges from time to time, but they really don't last that long.
Author here. My original post was a little ambiguous on this topic; I've updated it to make it clearer.
The tl;dr is that in Python, `time.time()` calls the c stdlib `time` function (at least in CPython), which follows the POSIX standard. It turns out that POSIX standard does _not_ mention timezones at all: https://pubs.opengroup.org/onlinepubs/9699919799/functions/t...
To wit, you can't actually assume that timestamps are UTC in Python, which is a different kind of insanity:
``` datetime.datetime.utcnow().replace(tzinfo=pytz.timezone("America/Toronto")).timestamp() ```
differs materially from
``` datetime.datetime.utcnow().timestamp() ```
I admit that I didn't fully explain the danger, because I thought it was somewhat self-evident: if you attempt to compare two datetimes correctly, you must know their timezones. Anyone who has used Google Calendar to schedule a meeting in SF when they live in NYC can attest to that.
> You only need a timezone if there was some kind of locality to the event (e.g.: when _and_ where this happened), but usually you can convert to local time. So storing UTC time is fine, adding the timezone in rare cases.
We're both saying the same thing, here.
While UTC is not _technically_ a timezone, most databases/programming languages/etc. let you attach UTC to a datetime. When you say that you're "storing UTC time", you are implicitly storing it with enough information.
The difference is that I don't like the implicit nature of assuming a timezone-naive datetime is UTC, because that is a very dangerous assumption to make. Just store the timezone, even if it's UTC!
It takes a little time to familiarize yourself, but you get very proficient with layers and home-row mods. The main benefit is that every single one of my fingers never has to move more than one key in any direction, and it has markedly improved my wrist health.
… do you have any idea of the costs that are associated with owning and operating a vehicle in Tokyo?
Thanks for the explanation! Very much appreciated.
The sub-statements in WITH are executed concurrently with each other and with the main query. Therefore, when using data-modifying statements in WITH, the order in which the specified updates actually happen is unpredictable. All the statements are executed with the same snapshot (see Chapter 13), so they cannot “see” one another's effects on the target tables.
1. https://www.postgresql.org/docs/current/queries-with.html#QU...Perhaps calling it the "Montréal effect" would be more apropos?
Many people in North America use a microwave every day. Does that mean they have or want a deep understanding of magnetrons? Likely not. Of course, this is because microwaves generally just work as expected. But I can't imagine a scenario where microwave home repair would be a thing that people would be okay with if they were unreliable.
Winter cycling is actually popular enough that our bike-share system has started to leave a portion of the sharing infrastructure out during the colder months. They put studded tires on the bikes, put the stations in locations where they aren't in the way of snow plows and the like, and people use them quite a bit! Something like 1,500-5,000 rides per day, just in the shared infrastructure. That doesn't count the even larger number of people here who have their own dedicated winter bike.
Last year there were 1.5 _million_ trips on a single section of a dedicated cycling path that runs through a very commercial part of town. We have so much bike traffic that there are bike-only traffic jams and long queues at stop lights (again, all on the dedicated/separated bike path). And you better believe that a lot of people shop on their bikes, myself included.
My only thought was that it was during the MSFT acquisition due diligence, and my username was an unfortunate victim of whatever compliance requirements they had to satisfy.
I had received an email several years ago informing me that it was going to be removed. They gave me the equivalent to a coupon for a free year of the github personal plan as compensation.
To this day it'll tell you that the username is "unavailable" if you try to sign up with it, and the page just 404s.
As a result you end up losing out on a large surface area of buyers who rely on their buying agent to find properties, which puts you at a disadvantage.
> So yes a phone can do all that, and it ALSO would be awesome, but just like with these glasses you can't ACTUALLY implement this.
A perfect summary, I think!
I wonder if much of this could be solved by OS-level functionality (or at least having it in a developer-accessible SDK) that allows the new "always-on" lock screens to immediately trigger an application on a single tap.
I know HN already has too much cynicism for my own liking, so it pains me to say: you can already do this with the phone you have in your pocket. Have a shortcut that enables audio dictation/photo mode/etc., and you're good to go.
The workflow for glasses (either these or some other hypothetical ones) would involve hitting a button and then having to either speak the command out loud or hit some other button to capture video/audio/etc., which seems more cumbersome than the phone approach that exists today.