I don’t think that’s really true of driving, pedestrians and cyclists are at a much higher risk of getting killed by a driver than a driver themself. There are huge negative externalities to driving
I love fastmail, I switched from Proton a couple years ago after deciding the trade offs to have encrypted email were not worth it, since even if I fully trust Proton, most emails come from or go to AWS, Outlook, or Gmail anyway. I have been extremely happy with the service. Fairly priced, very fast even with a huge inbox, and they don’t add unnecessary features or bloat. I thought I would use my OS’s mail apps but the fastmail app and website are so good I just use that.
The Fastmail desktop app is literally a wrapped version of their website but with the added feature of... get this... no back button (or equivalent shortcut).
My 30 years of muscle memory using webmail is made useless by this "app" because some web developer somewhere wants to cosplay as a desktop app developer now.
It's not an oversight either. It's an intentional choice to not have a go-back-to-previous-page keyboard shortcut. A customer support person said they would add it as a "feature request". Gee, thanks.
It might be worth learning their hotkeys because they're pretty efficient in many cases (potentially included cases where you want the back button). They work in the browser and the app:
It's just a weird choice to make. It's like they are forgoing the back hotkey to make it seem more like a "native" app. But it clearly isn't, and I can't think of any good reason to consciously omit it. Or... since they are likely using a framework (Tauri maybe? I haven't checked) to go out of their way to disable something that is already baked-in.
I'm using Fastmail for more than 9 years. Especially since they added offline support to their app, there's nothing left why I would even remotely consider leaving them.
Almost every email is going to or coming from US servers anyway. Better to treat email as insecure and use something else for more secure communication.
Correct. I mean if you send from ProtonMail to GMail (which will be 90% of private conversations) you're an open book anyway. And if you want to be sure then there's PGP et al.
For me it was search. The proton apps are the only way to access email on mobile, and on them and on their webapp the search barely functioned, even with full text search downloaded. The only way to reliably search my email was with Proton Mail Bridge on desktop, but for some reason it continuously was using CPU on my laptop and of course didn’t work on mobile. If they made a server version that I could put in a docker container on my server it would probably solve most of my problems with Proton, because then I could access it from the Mail app on my phone over IMAP.
As a Proton user - the main trade-off for me is that you are forced to use their apps on mobile, and those apps are pretty barebones and (on iOS at least) have none of the bells and whistles of a modern iOS app, such as Home Screen widgets.
Since I use my own domain for email, I am considering moving over to another provider once my subscription term is up. I really miss widgets.
no caldav support so I couldn't get my next appointment as a widget on my phone. Similarly, your contacts in proton are trapped there and cannot sync with any other system (such as your phone...)
limited quantity of aliases compared to fastmail. this is actually a really sticky feature with fm from what I've been seeing. I would have to rename a bunch of accounts or switch to using a catchall to transfer out.
When I cancelled Proton the subscription ended immediately instead of running out the clock on the time I had paid for. Left a really bad taste in my mouth.
Depends on the city. In LA, yes it’s very hard to live without a car. I live in Seattle and I live car free as well as many of my friends. It’s not that we can’t afford it, we’ve just built our lives around transit and biking and the city is pretty good for it. Then of course there’s NYC, which is likely better than most European cities for transit. But you’re right that the average here is far far worse when it comes to transit and living car free or car lite.
In the states if you want to live car free you can but you need to be strategic in where you live within a city. I have lived in a few from east to west coast, suburbs to urban. By selecting your place in a city carefully you can go car free or mostly car free.
Even in LA it's quite possible to live without a car if you live in the right neigbhorhoods like K-Town or any other centrally located one where both the Metro and buses are plentiful. LA's a huge place with varying amounts of density.
This. I’ve lived in both Seattle and LA. LA was significantly faster and easier to get to destinations than it ever was in Seattle. Unless you actually live in LA and use the transit, a lot of outsiders will always default to “LA transit bad” which is far from the reality.
Seattle was the worst city I’ve ever lived in and not owned a vehicle. It actually made me appreciate Portlands transit even more given the size of the region. LA has even more reliable transit than both, despite how prevalent and necessary most times a vehicle is in SoCal. In LA I was able to get around quickly and further with no drama. Seattle transit I know has been improving, but your routes, frequency, and speeds made me want to pull my hair out. This is also as someone who lived in Capitol Hill which is apparently the transit heaven of Seattle.
Interesting! How long ago was that? Seattle has higher transit ridership than both those cities and is rapidly expanding its transit system. I believe we are still leading the pack in transit ridership growth yoy. Maybe you were here before it got good? I’ve only lived here 5 years.
Pre pandemic. Seattle has more riders than Los Angeles? That’s…not right? I recall needing to rent a car to get nearly anywhere around Seattle, like if I wanted to get from home in Capitol Hill to Golden Gardens, that’s nearly an hour to go 8mi with multiple transfers. The issue with Seattle is it’s a small city with a giant body of the water in the middle of it, with not many bus lanes or hard rail.
Conversely, you can get from downtown LA to Santa Monica in the same amount of time, which is nearly twice the distance, direct. This was not to cherry pick a route either, just a popular dense neighborhood to somewhere scenic.
Sorry, I meant ridership per capita. In Seattle about 15% of people commute via transit (and I believe it’s the fastest increasing in the country), but LA is 6% and flat.
Seattle’s geography is conducive to transit, because there are many bridges where all traffic is constricted. That means point to point trips by car are often taking a similar route to buses. It also restricted the city’s ability to sprawl (although even suburban Bellevue is above LA at 8%).
The standard of service for nearly every bus line that operates in Seattle is 15 minutes frequency, even on weekends. Many lines operate every 10, and the new G Line that opened last year in fully dedicated bus lanes runs every 6!
Without RSC you have to wait for the user to download the application bundle before the request for content can even be sent to the server. So that means that the db queries and stuff are not even initiated until the client has the bundle and runs it, vs with RSC that stuff is all launched the moment the first request comes in from the user.
That doesn't seem to be how this implementation of RSC is intended to work. Here, client code triggers the RSC fetch, which is treated as any other sort of data fetch. Presumably, it still waits for client code to load to do that.
Also SSR, even in React, existed well before RSCs did, and that seems to be really what you are talking about.
SSR is different and does not provide the same performance of RSCs. With SSR you get the advantage of an initially rendered page, but you don’t have access to data or state. So you are just rendering placeholders until it hydrates and the client can request the data.
RSCs allow you to render the initial page with the content loaded right away.
That said, I am not sure about Tanstack’s implementation. Need to spend more time reading about this.
You have it reversed. SSR in react without RSC gives you access to data and state on the client. That's what the hydration does. RSC strips it out to make the bundle smaller. There is no hydration
I mean the state from the client, like cookies and URL params. You can get access to that in SSR through the framework specific APIs like getServerSideProps in Next, but it’s not a great solution.
> Without RSC you have to wait for the user to download the application bundle before the request for content can even be sent to the server.
This is an argument for not putting all your JS in one monolithic bundle and instead parallelizing data loading and JS loading. It's not an argument for RSC.
2nd RT: data (app server) and code (CDN) in parallel
Therefore you need two. But not all roundtrips are equal. A roundtrip to a CDN is much faster than a roundtrip to an application server and database, unless you have some funky edge database setup.
If you render on the server, your first roundtrip is slow because the client has to wait for the application server and database before it can show anything at all. If you render on the client then your first roundtrip is fast but the second one is slow.
Transit lines in many countries do support themselves by increasing productivity and tax revenue near the stations. It is not as direct as in Japan, where the train company itself captures the value created by its stations, but it’s effectively the same thing. Most places in the world with effective public transit systems are more like LA than Japan in how they are funded and operated.
So you can claim, and I agree, that it's supposedly an investment. Unfortunately, putting it in the hands of politicians to fund often means funds are taken away for other things. Where as, the private Japanese train companies fund themselves and it works.
This problem, along with general annoyances at Proton’s lack of focus on a good email experience pushed me over the edge to move to Fastmail. I’m so much happier. Proton Mail Bridge would often pin one core of my laptop CPU, draining my battery, and it was still slow to sync new email. With Fastmail, incoming mail is so fast that the verification codes are already there before I can alt tab over.
Proton’s pricing is really frustrating for me because I want to buy upgrades to only a few services like Pass and email. Your only option on their service is to select either Pass or Mail. You cannot buy both and you will be downgraded on one if you try to buy the other.
They really haven't improved Mail in a long time now. Still can't use your own keys, still can't have a clean unmangled export, still can't send using your own keys.
It's almost like Protonmail is intentionally hostile to key management outside of their control.
Same here, I've found too many bugs in Proton's email client and instead of fixing them they just release new products. FastMail support has been great, I think the developers themselves reply (some of the?) emails, going into technical details and being actually helpful.
I got a Garmin watch after being frustrated with the tech company watches lasting only hours on a charge. I charge this watch once a week and it does everything I realistically want from a smart watch:
- shows notifications
- tracks workouts
- silent alarm clock
- home assistant shortcuts
I'm a big fan of Garmin watches, it's really impressive what they've built. They're responsive, they have the smart features I want without the bloat I don't want, the battery lasts forever (if I don't use GPS at all it lasts something ridiculous like three weeks, with GPS it's still around a week). And they're so good I don't feel any urge to upgrade to a newer model even though the one I currently have came out in 2019. I bought it "renewed" 2.5 years ago at a significant discount and I could see myself happily using it for at least another 4-5 years.
Garmin watches are great! I wish the lighter/smaller models also had solar charger, but last time I checked only the bigger "ultra-durable" ones had it, but they're not that comfortable to wear.
I work on an open source server project that is deployed in many different contexts and with many different clients and front ends. GraphQL has allowed us to not feel bad about adding extra properties and object to the response, because if a particular client doesn’t want them, they don’t request them and don’t get them. It has allowed us to be much more flexible with adding features that only few people will use.
