That reminds me of the handwriting recognition approach [1] used in old Palm Pilot devices. Even though the shapes it expected you to draw resembled the corresponding letters, you would never draw them like that if you were writing on paper.

You knew that you were drawing something designed for a computer to recognise as unambiguously as possible, while being efficient to draw quickly and easy to learn for you. I feel like that's the kind of notion that voice interfaces should somehow expand upon.

[1] https://en.wikipedia.org/wiki/Graffiti_(Palm_OS)

Those other routes aren't in Sydney, though. Regional bus route numbers sometimes overlap with Sydney route numbers.

I definitely don't find myself complaining about them as I much as did 10 years ago. Back then, one of my local bus stops in Newtown had "what is the point of this?" written in marker over the timetable, and everyone who saw it smiled in agreement.

However, this could be explained by today's GPS tracking data, rather than improvements in reliability. When you open your transit app, you want to know when the next bus is, so you can find an alternative if the wait is too long. When it tells you the next one is in 3 minutes (which is an accurate estimate because of the GPS), you don't actually care if that bus is running 18 minutes later than originally scheduled.

For the bus I use for my commute, I don't leave either the house or the office until I see its GPS tracker pass certain points of the route. I've never had to wait for more than 3 minutes at a bus stop doing that. On occasions where there is no GPS feed, I treat that bus as "theoretical", and don't risk going out to try to catch it at its scheduled time, unless I'm desperate. But every time I did risk it, it ended up arriving right on schedule.

So I'd say the experience of catching buses has profoundly improved, but not necessarily because the reliability has improved.

And 10 years ago, we didn't have Opal readers, which are great, since together with having digital driving licenses on our phones, it has allowed many of us to completely forgo carrying a wallet.

Bus drivers are still as reckless and grumpy as they used to be though.

Good to hear, thanks. I forgot of course that smartphone were barely a thing back then so I can see how this improves choices massively.

There isn't much there to liquidate that still has any worth. They didn't have significant holdings of any of the major assets. That's kind of the main reason they were insolvent.

They also had this “hack” a day or two ago so it’s unclear what is left

A timestamp doesn't require TZ data because the timezone of the unix epoch is defined in UTC. To convert a timestamp into a meaningful datetime value, we need a timezone, otherwise there is loss of information.

The main issue is that .utcfromtimestamp and .fromtimestamp both return naive datetimes, instead of aware ones with the timezone property set to UTC or the local timezone respectively.

I was familiar with the issue described, but it was useful to learn the shortcut of passing a timezone to `now()`, since I used to rely on `utcnow().replace()`, which was needlessly verbose.

    # what I used to do:
    >>> datetime.utcnow().replace(tzinfo=timezone.utc)
    # what I'll be doing from now on:
    >>> datetime.now(timezone.utc)

It's doubly curious that there hasn't been a recent resurgence. I'd expect that the WFH trend would be making it more practical and sustainable for many.

During polyphasic experiments in my youth, my biggest obstacle was always securing reliable conditions to allow the daytime naps.

There are so many clever ways to code honeypots using obscure peculiarities of Solidity and/or Etherscan that there's little hope of being sure that it isn't a scam just by looking at the code and transaction history.

Fortunately, there are tools like Ganache, which you can run with `ganache-cli --fork` to reliably emulate locally what will happen when transactions are sent to mainnet. I would accept no substitute approach when dealing with suspect contracts.

Oh huh, I didn't know Ganache could do that, thank you!

The author of the article, Robert Miller, is a leading authority on MEV (Miner/Maximum Extractable Value). Those involved in MEV are quite a different bunch from most of the crypto crowd.

For one, they don't rely on "number go up" to make money, they use strategies similar to those used by HFT firms to make money from market inefficiencies. They generally don't have loyalty to a particular crypto platform, they just go wherever they can find a competitive advantage. They also tend to be much less politically outspoken and often left-leaning, in contrast to the vocal libertarian views that permeate the rest of the field.

They also most certainly aren't "imagining" making money. Most of their strategies are essentially elaborate forms of arbitrage, which are risk-free sources of profit by nature (until out-competed). Their only losses come from fees paid for deploying strategies that turn out to be unsuccessful. Even fees for failed transactions are pretty much a non-issue these days because of Flashbots.

That is a viable possibility, yes. You wouldn't need a "much larger fee" though, just 120% of the other transaction's fee would be enough to secure prioritisation over it.