At risk of sounding like a mindless futurist, I will say that the Transit App has considerably improved my experience of public transit in the US, because it doesn't tell me when the next scheduled ride is, but instead when the next actual bus is, based on realtime data provided by other Transit users onboard the vehicle.
The only time in recent memory that this screwed me was in SF trying to get a Muni that I thought was a surface route and was in fact underground. So I was standing at a trollybus stop directly over top of the station where I was missing my train.
The one major gap I still feel a lot as a visitor is wanting a transit-aware business search. In Google Maps the "search for X in this area" is a completely distinct workflow from "how to get to X by <mode>", and implicit in the first workflow is that you can infer how long it will take based on the crow-flies distance. And that assumption is very much not true if you are using transit. For example, I would love to be able to be like "show me three-star hotels ordered by transit convenience to X airport and Y event venue" and have it figure out both rides, and call out which ones will have what service level in the evening, overnight, etc.
Another failure mode I've seen is a tourist with their phone set to their home timezone having their Google Maps mentioning bus lines I wasn't familiar with (which were the late night service that wouldn't go by any time soon). This seems like a weird failure mode for the app to have, as it clearly had network connectivity and should have noticed the discrepancy (or at least provide a notice).
Appreciate the recc but what I'm trying to get at in the parent comment is that by that time you've picked X without having an overall picture of the transit story, you've often already lost. Basically, current route planning works well when you already know where you're going, but is much more limited when you're exploring the problem space that is where could I be going.
My internal thought process as a tourist is that I have a starting point and end point in a city, and some number of hours in between. I want to do some touristy things in that time, and I don't want to waste it all waiting for transfers. I'm not asking Google Maps to be a tour operator for me, but it also can't even help when I have a specific thing I need of which there are many instances, and I'm like... I don't care which electronics store I go to, I just need an electronics store and would like one that's convenient to where I am by transit. Or like, there are four Apple Stores in this city, which one is fastest to get to by transit?
Another recent example was having a seven hour layover in Tokyo where I had to do the Narita -> Haneda shuffle, and wanted to eat something not-airport-food during that time. I really struggled with getting Google Maps to show me where would be a good point to aim for a stop that was convenient by train to both airports; in the end I asked ChatGPT which suggested Ueno Station and I ate monjayaki which was delicious.
I was happy to see that x64 mini computers have really come along. Some of the units from China are really impressive with some exposed full PCI-E buses.
Arm64 is still limited for sure, but with Snapdragon and Windows finally committing to ARM I think the future is bright for that. Just not here yet.
A thunderbolt 3 connector is 4 PCIe lanes, isn't it? I know there can be compatibility gaps, but there are definitely TB-connected enclosure boxes available. NVMe connectors are also 4 PCIe lanes, and I believe any of those can be broken out and used for whatever (m.2 cellular data modems for example).
Are you thinking of plugging in actual consumer expansion cards, or are you wanting the lanes broken out on some kind of riser where they can go to hardwired stuff on a carrier board?
Thunderbolt isn't literally four PCIe lanes; Thunderbolt can encapsulate and carry PCIe traffic, and Thunderbolt controllers are typically connected with four PCIe lanes, though the amount of PCIe traffic a Thunderbolt link can carry is not necessarily as much as four PCIe lanes.
Directly exposing literal PCIe signals cuts out the pair of expensive Thunderbolt controllers.
What year was that? I was at a startup from 2010 onward and I'm pretty sure we had physical keys until about twelve people and after that it was straight to badges. There was never a time where you could just walk in.
Late 2010s. We actually did have badges but the doors were only locked outside work hours, so nobody carried them.
The thief had to walk past a security desk in the lobby, take the elevator up to our floor, walk past a front desk to the kitchen, then open a door to get to the office area. Probably sounded like enough layers for whoever was in charge of security at the time, but both desks were frequently unoccupied during lunch.
I know we had cameras too, but I never got updates on the investigation. I suspect it was an employee at one of the other companies in our building.
Interesting. I feel like most places still make you badge into the doors during business hours, and even specifically encourage not permitting tailgating, sometimes tied to a purported safety concern around being able to know who is in the building in an emergency... though honestly at most shops I bet no one has any idea how to get a report like "everyone who has badged in in since 6am this morning".
I would guess that by the time a response is being emitted, 90% of the actual work is done. The response has been thought out, planned, drafted, the individual elements researched and placed.
It would actually take more work to condense that long response into a terse one, particularly if the condensing was user specific, like "based on what you know about me from our interactions, reduce your response to the 200 words most relevant to my immediate needs, and wait for me to ask for more details if I require them."
I would say more significantly, 4 million people can read it. The changes required for any given quarter are probably miniscule, but the tricky part is getting up to speed on all those legacy patterns and architectural decisions.
A model being able to ingest the whole codebase (maybe even its VCS history!) and take you through it is almost certainly the most valuable part of all.
Not to mention the inevitable "now one-shot port that bad boy to rust" discussion.
I think the argument is more that working rust code is better than working Python, and AI assistance makes it more tenable for average developers to successfully produce working rust code, and in particular is helpful for navigating the gap between "code written" and "code compiling" (eg why is the borrow checked mad at me).
This advice makes most sense for tools that have a clear linear flow from beginner to expert. As soon as something is complex enough to have multiple different personas or desired outcomes for the novice user it's considerably harder to structure docs pedagogically.
The extreme case of this is something like Nix, which is notorious for terrible docs, and I think that's in large part because even the basic "install my first package" could involve profiles, environments, flakes, whatever; there's like five ways to do everything and which one you want depends a lot what your "real" eventual goal is.
The only time in recent memory that this screwed me was in SF trying to get a Muni that I thought was a surface route and was in fact underground. So I was standing at a trollybus stop directly over top of the station where I was missing my train.
The one major gap I still feel a lot as a visitor is wanting a transit-aware business search. In Google Maps the "search for X in this area" is a completely distinct workflow from "how to get to X by <mode>", and implicit in the first workflow is that you can infer how long it will take based on the crow-flies distance. And that assumption is very much not true if you are using transit. For example, I would love to be able to be like "show me three-star hotels ordered by transit convenience to X airport and Y event venue" and have it figure out both rides, and call out which ones will have what service level in the evening, overnight, etc.
reply